February 26, 2012
On Sunday, February 26, 2012 12:24:09 Kagamin wrote:
> On Saturday, 25 February 2012 at 23:32:24 UTC, Jonathan M Davis
> 
> wrote:
> > which resets the stack trace.
> 
> This is the issue, you're trying to address with these proposals?

It's _an_ issue, not the only issue. The bigger issue there is that you're forced to duplicate catch blocks when you want to catch several disparate exceptions and handle them identically (either that, or you're forced to catch their base type and examine their actual types individually). The stack trace part may even end up being fixed by changing the rethrowing behavior. It's just one of the things that would be affected by making it possible to catch disparate exceptions with the same catch block. It's not the primary thing.

As for the exception hierarchy or Variant[string] stuff, that has _nothing_ to do with resetting the stack trace. They solve completely different issues.

- Jonathan M Davis
February 26, 2012
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.

This is what I like to see.

> 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) {}
>
> It is unclear which we want to do or whether we want to do both. So, that
> still needs to be discussed further. But it's fairly clear that the majority
> want a feature along the lines of one or both of those two suggestions.
> However, regardless of which we choose, someone is going to have to take the
> time to implement it, since odds are that Walter isn't going to do it. So,
> whether we end up with a feature along these lines is highly dependent on
> whether anyone is willing to take the time to implement it and get it accepted
> by Walter.

Please do not do that. It will introduce additional set of bugs and increase maintaining effort for the sake of small syntactic sugar improvements. I think current exception handling style is enough. Its successively used in C# for years.

If one wants to catch more than one exception in one handler, she just catches the first common base class such as Exception and then tests for concrete derived class inside catch handler:

catch (Exception e)
{
    if (cast(MyException1)e)
    {
        // catch MyException1
    }
    else if (cast(MyException2)e)
    {
        // catch MyException2
    }
    else
        throw;
}

I see nothing difficult in that.

> 3. We should add a Variant[string] property to Exception. Every derived class
> will then populate it with the values of its member variables in their
> constructors, and code outside of the exception classes can choose to insert
> other values into the table which are useful for the particular programs that
> they're in but which don't make sense to put in the exception types
> themselves.
>
> A free function will then be designed and implemented which will take some
> kind of format string along with an exception and will then allow you to
> generate a message from that exception using whatever formatting you want
> using the hash table to generically obtain the values from the exception
> without needing to catch or know the exact type of the exception. e.g.
>
> catch(Exception e)
> {
>      writeln(magicFormattingFunction(formatStr, e));
> }
>
> This Variant[string] property would _not_ replace having direct member
> variables in derived exceptions. Rather, it would allow us to make sure that
> we only put member variables in derived exceptions when they belong there, and
> code which wants additional data but not a new exception type can use the hash
> table to hold it. And of course, it also gives us the foundation to build the
> fancier string formatting capabalities.

Please no (sorry Andrei). This whole idea comes from the fact that deriving a class like this:

class MyException : Exception { }

adds code bloat to executable. This is mostly an implementation issue of classes as a whole and I don't like to fix implementation issues by introducing not D'ish style to something as fundamental as exceptions. Imagine those hundreds of newcomers saying "WTF, why not just derive from base exception class?".

> There were other ideas that were discussed in the thread, but I think that
> these are the ones that we have at least some consensus on. However, given the
> mess that thread is, we really should make it clear in a separate thread (this
> thread) that we have a consensus that these are indeed the things that we want
> to pursue to improve exceptions in D and Phobos. Thoughts? Opinions?

Why there is code bloat at all? Why full RTTI for a class is generated when I don't want to? I know that some bare minimum must be generated for virtual function, dynamic casts and interface support. But why can't it be done more compact?

Deriving a class without adding a single member should add *minimal* number of bytes to executable, not a code bloat! What if I don't need RTTI at all, when I don't use typeid(), casts, virtual functions and interfaces?

I explained some eventual improvements in this post: http://forum.dlang.org/post/ji0i7p$2mck$1@digitalmars.com
February 26, 2012
On 02/26/2012 07:46 PM, Piotr Szturmaj wrote:
>
> Please do not do that. It will introduce additional set of bugs and
> increase maintaining effort for the sake of small syntactic sugar
> improvements. I think current exception handling style is enough. Its
> successively used in C# for years.
>

Do you realize that syntactic sugar improvements are trivial to implement (just re-write the AST a little), and have almost no influence on the existing code base?
February 26, 2012
Timon Gehr wrote:
> On 02/26/2012 07:46 PM, Piotr Szturmaj wrote:
>>
>> Please do not do that. It will introduce additional set of bugs and
>> increase maintaining effort for the sake of small syntactic sugar
>> improvements. I think current exception handling style is enough. Its
>> successively used in C# for years.
>>
>
> Do you realize that syntactic sugar improvements are trivial to
> implement (just re-write the AST a little), and have almost no influence
> on the existing code base?

I didn't know that, I was just a bit sceptical. If they're really trivial then I see no reason they couldn't be made.
February 26, 2012
Timon Gehr:

> Do you realize that syntactic sugar improvements are trivial to implement (just re-write the AST a little), and have almost no influence on the existing code base?

In my opinion it's good to have a syntax to catch a many exceptions "at once".
But this is yet another special syntax case for a sequence of things, where instead a built-in tuple syntax is more uniform and better. Tuples are a data structure more fundamental and more important than associative arrays.

In Python this syntax caused troubles: http://www.python.org/dev/peps/pep-3110/

Bye,
bearophile
March 02, 2012
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.




1 2 3
Next ›   Last »