Conclusions of the exception discussion

[Don]

On 25.02.2012 06:53, Jonathan M Davis wrote:
> Okay, the "The Right Approach to Exceptions" thread is a huge, confusing mess
> at this point without a clear, definitive conclusion, and we need one. So, I'm
> posting here, in a new thread, what appears to me to be the conclusion that
> that thread comes to and see if we can get some sort of consensus on this.
>
> There are three things that that thread appears to conclude that we should do
> to improve the current situation with exceptions in Phobos and in D in
> general:
>
> 1. Phobos' exceptions should be reorganized into a class hierarchy designed
> such that the exceptions can be reusable outside of Phobos. We will no longer
> follow the policy of an exception per modules. A module may declare 0 to many
> exceptions depending on the problems that it would be reporting by throwing
> exceptions, and some modules will reuse the exceptions from other modules
> where appropriate.
>
> The exact set of exceptions that we're going to end up with and how the
> hierarchy will be laid out has yet to be determined. It may or may not be
> similar to what Java and C# have. We will probably look at what they have as
> examples but will do whatever we decide works best for D and Phobos, and that
> may or may not have any relation to what those languages do. This will likely
> start with a minimal number of exceptions and will grow as necessary rather
> than trying to create a lot of exception types up front which we may not ever
> need. Regardless, we may know that we want a hierarchy, but the exact
> hierarchy has yet to be determined.
>
>
> 2. We should add a feature to the language to make it possible to catch
> multiple exception types with a single catch statement. There are two
> suggestions.
>
> A. Do something similar to what Java 7 is doing and make it possible to simply
> list the exceptions that a particular catch statement accepts. That catch
> block will then catch any of the matching exceptions, and the type of the
> variable will be their most derived common type. One possible syntax would be
>
> catch(e : Ex1, Ex2, Ex3) {}
>
> B. Make it possible to add a condition which would be run when the catch
> statements are processed to allow you to catch based on other stuff in addition
> to the type. The condition would be a condition run at runtime rather than a
> compile time condition like template constraints. e.g.
>
> catch(MyException e) if(e.prop == value) {}

The difficulty with that sort of thing, is that the stack is in a 
transitory state while it's working out which exception to catch, and 
the 'e' variable doesn't quite exist yet.

I wrote the exception chaining implementation for Windows, and what I 
found interesting is that Windows SEH works rather like that.
Each function with a catch handler gets called, and (roughly) returns a 
bool saying if it do the catch. There really aren't any rules for what 
that function can do, there's absolutely no reason for it to be 
type-based. In fact using type-matching seems quite odd, in C++ it's one 
of the very few built-in things which uses run-time type info. I think 
that any pure function could be used instead.