The Right Approach to Exceptions

[Jonathan M Davis]

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 
now.

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 
module.

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