The Right Approach to Exceptions

[Jonathan M Davis]

On Monday, February 20, 2012 18:38:08 Andrei Alexandrescu wrote:
> On 2/20/12 6:25 PM, H. S. Teoh wrote:
> > This is what I mean by not being able to depend on whether some data is
> > there. Ultimately, to do anything useful with the info in the object,
> > you need to know what's there.
> 
> No. You do realize you are positioning yourself straight against every
> OO principle there is? The entire OO world is predicated on the
> assumption you _can_ do useful stuff with an object WITHOUT knowing
> what's there.

Exceptions aren't very OO really. Aside from getting a string out of them, you 
generally don't have any polymorphism involved, and even with the string, 
there's a good chance that you don't. For instance, the message field which 
toString uses to generate its string is passed as an argument to Exception's 
constructor.

With exceptions, it's the types that matter. It's not a case of changing 
behavior based on implementation. With OO, you try _not_ to care about what 
the type is. With exceptions, on the other hand, you care a great deal. It's 
inverted from OO. Exceptions hold data but not much behavior. The behavior 
goes in the catch blocks.

If we had a construct which allowed inheritance but not polymorphism (which we 
don't, since for better or wors, inheritance is conflated with polymorphism in 
D), then that would make a lot of sense for exceptions.

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.

- Jonathan M Davis