The Right Approach to Exceptions

[Jonathan M Davis]

On Monday, February 20, 2012 12:45:57 Andrei Alexandrescu wrote:
> On 2/20/12 12:23 PM, Jonathan M Davis wrote:
> > I don't see how you could possibly make that uniform. It's very
> > non-uniform by its very nature. The handling _needs_ to be non-uniform.
> 
> No, it doesn't, and if you just hear me out for a second you'll see how.
> It's very simple. Formatting is all about pairing symbolic names with
> data. A format engine would load a string template that uses symbolic
> name such as "file", "line", "IP", "port", and a context which contains
> bindings of these names to values. That way formatting does not need to
> know what an IP means etc.
> 
> >> The stringTemplate function loads the formatting template from a table
> >> indexed on typeid(e).toString() and formats it with the info. It's
> >> simple factorization.
> > 
> > That only works in this particular case, because it happens that the code
> > is just figuring out how to translate the exception into an error message
> > without trying to recover. If you want to do anything fancier (like
> > suggest the flag that the user probably meant), you need those extra
> > fields in the exceptions.
> Sure. Again, this is not advocating replacement of exception hierarchies
> with tables!

Okay. If all you're looking to do is provide a templating mechanism for 
exception messages, then fine. If it saves on code, great. I question that it's 
worth the complexity, but maybe it would be a big improvement. I suspect that 
we'd have to implement it to really find that out.

But I think that the exceptions themselves should be organized into a class 
hierarchy such that you can catch them based on type in a hierarchical manner 
and access their member variables like you'd access any object's member 
variables. Using a variant for that just complicates the code which actually 
wants to handle the exceptions rather than simply print out an error message.

- Jonathan M Davis