|
From: Ø. H. <oyv...@zy...> - 2008-09-09 08:08:04
|
On Tue, Sep 9, 2008 at 3:12 AM, Duane Ellis <op...@du...> wrote: > Øyvind Harboe wrote: >> >> - please remove the translation from error code to string. OpenOCD is >> moving >> *away* from using the return value as anything but a boolean >> success/failure. >> > > I disagree, Sure - in the future when this change you describe is done. > Or as you delete each of these #define ERROR codes - delete them from the > list. > > meanwhile, I believe they should stay. > > There is a deeper reason though - perhaps - I am looking too far into the > future. Or maybe seeing a pit fall you are not seeing yet. > > I believe this will be needed shortly. For example - in unix C code, one can > call "read()" and get an ERROR - that is not really an error, instead it > might be "EWOULDBLOCK" (error would block). When, where, and how to handle > those 'in that case it is not an error' should be left to the TCL code to > manage. This is an example of a bad API. We don't need to make such an API to Tcl. > In that case - there are most likely things the TCL code might want to > handle differently in some cases - each - depending upon the *exact* error > at hand. I'm against using error codes for this sort of code flow. That makes the error codes part of the API. Shudder. OpenOCD is currently moving in the direction that the error codes are *not* part of the API. > Back to the UNIX example. > If I call read() - and I get an "EIO" error - would bail. > If I instead, got "EWOULDBLOCK" - I would take other action. This sort of functionality should not be piggybacked onto the error codes, but made more explicit in the API beforehand. > Today - target-object examine & poll return parse able strings with > *HARD*CODED* numbers. I don't want to expose the error codes to tcl in text or in decimal. The error codes are not part of the API. -- Øyvind Harboe http://www.zylin.com/zy1000.html ARM7 ARM9 XScale Cortex JTAG debugger and flash programmer |