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.
