The Right Approach to Exceptions

[Jonathan M Davis]

On Monday, February 20, 2012 15:12:08 Andrei Alexandrescu wrote:
> On 2/20/12 2:53 PM, H. S. Teoh wrote:
> > On Mon, Feb 20, 2012 at 05:31:28PM -0300, 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.
> > 
> > Hmm. This is a valid point. Sometimes you want to add contextual details
> > to an exception in order to provide the final catching code with more
> > useful information. Otherwise you may end up with a chain of mostly
> 
> > redundant exception classes:
> [snip]
> 
> Yah, it does look we need to better investigate the Variant[string]
> info() primitive.

In my experience, the type is very much tied to the context. When a particular 
type of error occurs, there's a particular set of information that goes with 
that, and that doesn't generally change. So, you don't end up with a bunch of 
types which are solely there to add additional information.

Using variant means moving to dynamic typing and problems that you don't see 
until runtime, whereas having the data as direct member variables is 
statically checked.

Having the ability to add extra information via Variant[string] may not be a 
problem, but doing that for everything _would_ be. It's far more bug prone, 
and the fact that it would be error handling code which would have the bugs 
would make them _far_ harder to catch and fix.

I definitely think that we should favor putting data in member variables, not 
in a hashtable of Variants.

- Jonathan M Davis