On Sat, 18 Feb 2012 20:21:46 -0600, Jonathan M Davis <jmdavisp...@gmx.com> 
wrote:

On Saturday, February 18, 2012 19:59:52 Robert Jacques wrote:
But you _always_ know what went wrong:

No you don't. Take getopt for instance. If I want to appropriately handle what
went wrong that caused getopt to throw an exception, I need information on
what went wrong. I need to know what flag failed and why it failed (e.g.
unknown or it was given an invalid value). Exception doesn't give you any of
that. You need a more specific exception type to get that information.

There's a difference between knowing what went wrong and knowing how to fix it. 
That said, I fully agree with your excellent post. My intent wasn't to propose 
or support the use of error codes, but to observe that effective use typed 
exceptions tends to look a lot like error code. For instance, the function 
calling getop knows how to use getop, what getop's exceptions are and can 
(hopefully) use the exception's extra information to recover gracefully. But 
now consider the function that calls the function that calls getop. It probably 
doesn't even know that getop can be called and that its exceptions can be 
thrown. Even if it did, it probably doesn't have the access to getop needed 
utilize that information in the recovery process. Worse, if function A could 
leverage the type exception, it probably means A and B's implementations are 
heavily coupled leading to long term maintenance issues.

With the number of times 'bad exception hierarchy' has come up in this discussion and the 
number of times I've seen MyClassException be a simple wrapper around whatever happens to 
throw inside MyClass, I guess I'm just ready to explorer solutions out of the box. All my 
brains have been able to come up with so far is a) beef up exception to aid generic 
recovery code and b) add a TupleException/VariantException that would allow you to 
express enforce(isFlagGood[i], i, flags[i], "My flag error message"); or 
something. i.e. a way to provide extra info when available in the leanest possible manner.

Reply via email to