The Right Approach to Exceptions

[H. S. Teoh]

On Sun, Feb 19, 2012 at 02:53:04PM -0800, Jim Hewes wrote:
[...]
> Two, the exception hierarchy is orthogonal to the library.

Yes, yes, and yes! You have identified one of the causes of the current
problems with the exception hierarchy.


[...]
> So changing the library functions---adding or removing them--- doesn't
> require changes in the exception hierarchy. Perhaps ParseException
> could then have a field that highlights the text that could not be
> parsed. This could be generally for all parsing type application.

For a well-defined library like Phobos, we really shouldn't be defining
new exceptions in each module. Rather, (almost) all exceptions should be
collected in a common place, organized as a clean hierarchy without
being unnecessarily bound to any particular module. Modifications to the
exception hierarchy need to be properly evaluated before being committed
to the codebase.

Of course, there are some exceptions that are specific to a module;
those obviously belong in their respective module. But generally
speaking, exceptions should fit into a clean classification hierarchy
independently of which module first introduced them.

Just because exception X was first introduced by module M doesn't mean
that it's specific to module M; it may encapsulate a larger class of
problems that M just happens to touch.

By separating the exception hierarchy from the module hierarchy, we can
clean up a lot of the mess that resulted from conflating the two.


T

-- 
Chance favours the prepared mind. -- Louis Pasteur