On 2/20/12 2:51 PM, Jonathan M Davis wrote:
On Monday, February 20, 2012 17:31:28 Juan Manuel Cabo wrote:
...
Sure. Again, this is not advocating replacement of exception hierarchies
with tables! ...
Andrei
I think that the case of rethrowing an exception with added detail is the
worst enemy of clean Exception hierarchies.
The idea of Variant[string] remedies that case without creating a new
exception class just for the added fields. If that case is solved, then the
tipical need for creating new exception types that don't really aid
selecting them for catching and recovery is solved too.
Having derived exceptions with additional information is a _huge_ boon, and I
contend that it's vasty better with variant, which would be highly error
prone, because it's not properly statically checked. Changes to what's put in
the variant could kill code at runtime - code which by its very definiton is
not supposed to be the normal code path, so you're less likely to actually run
into the problem before you ship your product. Whereas with the information in
actual member variables, if they get changed, you get a compilation error, and
you know that you have to fix your code.
Rethrowing is a separate issue. And in many cases, the correct thing to do is
to chain exceptions. You catch one, do something with it, and then you throw a
new one which took the first one as an argument. Then you get both. That
functionality is already built into Exception.
I think we'd be quick to dismiss Juan's point. There are many execution
contexts for any given exception, and summarily saying that we'll handle
them with distinct types doesn't sound exactly scalable. I've long
wanted to be able to plant context information in a scope, that was
automatically added to any exception possibly leaving that scope.
Andrei
