On Apr 14, 2009, at 2:11 PM, Øyvind Harboe wrote:
So because it isn't that way today, we shouldn't set a policy to do so inthe future?I think that would be moving in the wrong direction, yes.I'm in favour of a boolean success/failure return value and other mechanismsto convey other information.
boolean success/failure doesn't really give the programmer a chance to decide what to do. I agree that the usage of return codes in OpenOCD today is a mess, but careful use of well-defined error codes means that a lot of "log a message and die" conditions today would become handled internally or would be repackaged with a more meaningful error at a higher level.
I've just spent 2 years defining a fairly large API entirely in C for a new problem space. After a few false starts, we have managed to design an error system that conveys meaningful error codes to the programmer but also provides ways to map those errors to user-friendly strings that can be presented to the user. All internal errors are mapped onto the same error code space as external errors, but they are handled in a appropriate manner when possible rather than just blindly returning them to the next layer up. This allows the code when to decide to do recovery versus failure.
Why should information about what went wrong be limited to 32 bits of information?
It doesn't strictly need to be. For example, the API I reference above returns a 32-bit error code but also takes an optional value- return parameter that provides domain-specific error information. These additional parameters can also be stacked so nested failures can be communicated. This ultimately provides a richer and more friendly error system for both the developer as well as the end user of a tool using the API. The return codes are for programmatic handling while the additional parameter is for communicating errors to users.
A c++, java or tcl exception can contain a heck of a lot more useful information.
And can also cause a lot more problems. Having a deeply nested function throw an exception can cause the upper layers to get in all sorts of weird states. Every layer needs to be aware of what exceptions can be thrown by what functions so that appropriate cleanup can be done. You may as well just return a return code.
-- Øyvind Harboe PayBack incident management system Reduce costs and increase quality, free Starter Edition http://www.payback.no/index_en.html
-- Rick Altherr kc8...@kc8apf.net"He said he hadn't had a byte in three days. I had a short, so I split it with him."
-- Unsigned
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
