Errors in user input should detected where user input is parsed. This includes checks that pre-conditions for internal API calls are satisfied.
Internal functions should use an assert. Moving user error diagnostics from the user input functions to internal functions is a clear violation of the API layers. To make this more clear, the moment you have a user input handler that calls more than one internal function the user messages you have piggy-backed on the internal APIs will become less and less meaningful to the user. The fact that we have user function like "drscan" that just maps to exactly one internal API call is merely a coincidence and should not be an excuse to let Brownian motion cause the drifting of user error diagnostics into internal API layers. Michael On Tue, Jun 9, 2009 at 9:39 AM, Øyvind Harboe<oyvind.har...@zylin.com> wrote: > I'm satisfied that I've put the performance issue with checking at too > low a level on the radar. > > I'll leave this to Zach's judgement (he's the one who's working on it > currently), but I'm reserving the right to raise an objection later based > on measured performance problems(referring to Rick pointing out > that performance should be dealt with by measurements and > not speculation). > > I very few concerns that it will be fundamentally hard to address any > documented performance issues in this regard, unless something > radically new crops up in terms of doing *extensive* runtime checking. > > > > -- > Øyvind Harboe > Embedded software and hardware consulting services > http://consulting.zylin.com > _______________________________________________ > Openocd-development mailing list > Openocd-development@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/openocd-development > _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
