The Right Approach to Exceptions

[Jonathan M Davis]

On Monday, February 20, 2012 20:36:16 Andrei Alexandrescu wrote:
> On 2/20/12 7:07 PM, Jonathan M Davis wrote:
> (Cloning and comparison are also essential polymorphic methods to
> implement.) But then again the view "exceptions are wildebeests" is
> coming straight from inside the box. We want to improve on that.

Neither of which need to be done much with exceptions.

> I don't think inheritance without subtyping would help any. C++ has it
> (non-public inheritance) but that didn't improve exceptions one bit.

I don't think that it would necessarily improve them. My point was that 
polymorphism isn't of much use for exceptions. So whether they are polymorphic 
or not is generally irrelevant.

> > It doesn't really hurt us that exceptions have polymorphism, but it
> > doesn't
> > generally help them do their job at all. If you're going to do anything
> > beyond simply print an error message, you need to know what the exception
> > type is and what data it has. And that's not OO at all.
> 
> Or you need to implement a key-value interface that allows printing of
> an elaborate error message.

You need to know the type regardless. And the information that an exception is 
going to have is very strongly tied to its type. I'd argue that in the general 
case, using a key-value interface is a huge step down from having the 
information be fields in the type that it goes with. It may help with printing 
elaborate error messages, and it would allow you to add information to an 
exception which wouldn't generally be there, but it helps little-to-none in 
actually handling exceptions and in fact makes it worse, because then you're 
moving what would be compilation errors to runtime.

It may be that the hashmap may be worth adding, but I'd consider it bad 
practice to use it when putting the variables in the type itself would work. 
It's only when you need to add information which wouldn't normally be in the 
exception that it makes much sense.

- Jonathan M Davis