The Right Approach to Exceptions
Jonathan M Davis
jmdavisProg at gmx.com
Mon Feb 20 14:25:35 PST 2012
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:
> 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
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
More information about the Digitalmars-d