The Right Approach to Exceptions
Jonathan M Davis
jmdavisProg at gmx.com
Fri Feb 24 15:48:47 PST 2012
On Friday, February 24, 2012 16:38:31 Steven Schveighoffer wrote:
> On to my second point. One of the issues I have with Java is that
> exceptions are *overused*. For example, EOF should not be an exception,
> most files have ends, it's not a very exceptional situation. If there is
> an intuitive way to use an existing return value to convey an error rather
> than an exception, I'd prefer the return value. There is a runtime cost
> just for setting up a try/catch block, even if no exceptions are thrown.
It's definitely true that Java uses exceptions when they shouldn't - EOF being
a good example of that. Exceptions should almost always only be used when
something actually goes wrong. EOF is not something going wrong.
However, Java does have a great exception hierarchy, much of which is
standard. And that's a lot better than having only a handful of unrelated
exceptions, let alone having all exceptions be specific to a module like we do
So, we really have 2 problems here:
1. Phobos doesn't have a proper exception hierarchy. Its exceptions need to be
better organized according to the problem that they indicate rather than by
2. There are something things that can be done to Exception and how exceptions
work in D to help resolve issues related to wanting to catch and handle
exceptions without having to catch all exceptions that match their common base
type or otherwise have to duplicate code among catch blocks.
The two proposals that seem best for this are
1. Being able to annotate catch blocks in some manner to enable them to catch
multiple, specific exceptions - either by using some kind of condition
catch(Ex1 e) if(condition)
which, as you point out, would have to be done at runtime, or by doing
something similar to what Java 7 is doing and make it so that multiple
exceptions can be caught with the same block
catch(Ex1, Ex2, Ex3 e)
and e ends up being the most derived type that is common to them.
2. Andrei's Variant[string] proposal, which would enable a generic formatting
scheme with string templates which a free function could use to generate
messages from exceptions without caring about the actual exception type. It
would also allow you to tack on extra information to the exception which
wouldn't normally be part of that type of exception but your particular
program needs for some reason.
So, if we better organize Phobos' exceptions, implement a multi-catch feature,
and implement Andrei's Variant[string], then Phobos' exceptions will work far
better (and by far more reusable), and some of the greater shortcomings of D's
exceptions themselves should be mitigated, if not eliminated.
Naturally, that still won't stop people from doing stupid things with
exceptions in their own code (like throwing on EOF), but we'll have a good
setup for those who use exceptions properly, and we should be able to avoid
putting stupid uses of exceptions in Phobos, simply because the code is open
and peer-reviewed, and I think that most of the people around here agree that
using exceptions for stuff like EOF is stupid.
- Jonathan M Davis
More information about the Digitalmars-d