DIP33: A standard exception hierarchy

[Jonathan M Davis]

On Monday, April 01, 2013 21:33:22 Lars T. Kyllingstad wrote:
> My problem with subclasses is that they are a rather heavyweight
> addition to an API. If they bring no substance (such as extra
> data), I think they are best avoided.

Except that they're extremely valuable when you need to catch them. Being able 
to do something like

try
{
 ...
}
catch(FileNotFoundException fnfe)
{
 //handling specific to missing files
}
catch(PermissionsDeniedException pde)
{
 //handling specific to lack of permissions
}
catch(FileExceptionfe
{
 //generic file handling error
}
catch(Exception e)
{
 //generic error handling
}

can be very valuable. In general, I'd strongly suggest having subclasses for 
the various "Kind"s in addition to the kind field. That way, you have the 
specific exception types if you want to have separate catch blocks for different 
error types, and you have the kind field if you just want to catch the base 
exception.

If anything, exceptions are exactly the place where you want to have derived
classes with next to nothing in them, precisely because it's the type that the
catch mechanism uses to distinguish them.

- Jonathan M Davis