Re: [Openocd-development] [PATCH] process reset - error2string function

[Duane E. <op...@du...>]

Ø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.

Just like often the C code calls & ignores error results.

EXAMPLE
	TCL code wants to invoke a "target poll" - which - might fail right now.
	But - it is not always an error if it fails.
	
In TCL, we sort of want "target try-poll-do-not-error-if-it-fails-return-why-it-failed" type function.

What you describe is: It fails no matter what. Simple GO and NO/GO.

Today - the target-object commands: 'target0 poll' and 'target0 examine' fail by way of throwing and error and returning a 'parse able string' see "target.c, line 3501" same with "target0 examine" (line 3486).

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.

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.

Not unlike the examine & poll problems.

Today - target-object examine & poll return parse able strings with *HARD*CODED* numbers.

My intent and belief is this: 

	as we get through this 'reset change' 
	I fully suspect we will encounter problems like 'read()' 
	or a variation of that problem.

	I cannot predict them yet.

TCL works better with strings. 

Human programmers read strings better then number -104

If I got an 'error -104' the TCL code *might* need to ignore

TCL & C can not easily share "#defines".

Hence, the translation.


-Duane.