> It's currently 'catch(auto e : E1, E2, E3)' but changing the syntax is
> trivial if everyone decides they want it.
>
We should be consistent and allow to specify a type instead of auto.
The exception types (E1, E2, E3) should expand TypeTuples similar to how you
declare base classes.

alias TypeTuple!(SocketTimeOut, SocketFooBar) SocketExceptions;

try
{
    bind(...);
    listen(...);
}
catch (IOException io : SocketExceptions)
{
}

As for the syntax how about '=' assigning a catched exception.
catch(IOException io = E1, E2, E3)
catch(auto io = E1, E2, E3)

The colon is used for type conversions, where left implicitly converts to right.
catch(E1, E2, E3 : IOException io)
catch(E1, E2, E3 : auto io)

"deadalnix" <deadalnix@gmail.com> wrote in message news:jiagbg$liu$1@digitalmars.com...
> Le 25/02/2012 07:26, Daniel Murphy a écrit :
>> https://github.com/D-Programming-Language/dmd/pull/738
>
> I do think this approach have a flaw. If we go in that direction, then it push devs to create new Exception type just to catch them, because this is the only way we have.
>

This is a different issue to whether or not we have the syntax to catch multiple exceptions with a single catch block.

> If I understand properly your pull request, the compiler will be duplicating catch block ? If it is the case, would it be possible to use static if to use type specific stuff of E1, E2 or E3, depending on which one we are facing ?
>

No, it just creates stub catch blocks that jump to the real one. Duplicating the blocks would have weird effects on things like static variables.  I think that kind of code duplication is better done with something that works like mixing in case statements.

catch(auto e : E1, E2) { body; }
->

catch(E1 e)
{
  goto catchE2;
}
catch(E2 e)
{
catchE2:
  body;
}

Could you give a code example of what you mean?  You can still use multiple catch blocks perfectly well with this patch.
  "Kevin Cox" <kevincox.ca@gmail.com> wrote in message news:mailman.97.1330172953.24984.digitalmars-d@puremagic.com...
  I think there should also be multiple catches so that you can deal with different exceptions different ways without trying to upcast them over and over again.

  On Feb 25, 2012 1:30 AM, "Daniel Murphy" <yebblies@nospamgmail.com> wrote:

    "Jonathan M Davis" <jmdavisProg@gmx.com> wrote in message
    news:mailman.93.1330149312.24984.digitalmars-d@puremagic.com...
    > 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.

    Waaaay ahead of you here.

    https://github.com/D-Programming-Language/dmd/pull/738

    It's currently 'catch(auto e : E1, E2, E3)' but changing the syntax is
    trivial if everyone decides they want it.

"Martin Nowak" <dawg@dawgfoto.de> wrote in message news:op.v98ik4hysqugbd@dawg-freebsd.lan...
>> It's currently 'catch(auto e : E1, E2, E3)' but changing the syntax is trivial if everyone decides they want it.
>>
> We should be consistent and allow to specify a type instead of auto.

That's a very good idea.

> The exception types (E1, E2, E3) should expand TypeTuples similar to how
> you
> declare base classes.

Oops, I meant to do this and completely forgot.

> As for the syntax how about '=' assigning a catched exception.
> catch(IOException io = E1, E2, E3)
> catch(auto io = E1, E2, E3)
>

That syntax (sort of) already means declare variables io, E2 and E3.

> The colon is used for type conversions, where left implicitly converts to
> right.
> catch(E1, E2, E3 : IOException io)
> catch(E1, E2, E3 : auto io)

And that looks like three template arguments, sorta...

The syntax I've implemented was 'inspired' by the base class list syntax.
When base class protection is removed it could even use the same parsing
function.  It's listing derived classes, not base classes, but this is the
closest thing in D syntax I could find.
It also works with typetuples in the same way.

But anyway, I'll implement whatever gets W approval.

Le 25/02/2012 14:11, Daniel Murphy a écrit :
> "deadalnix"<deadalnix@gmail.com>  wrote in message
> news:jiagbg$liu$1@digitalmars.com...
>> Le 25/02/2012 07:26, Daniel Murphy a �crit :
>>> https://github.com/D-Programming-Language/dmd/pull/738
>>
>> I do think this approach have a flaw. If we go in that direction, then it
>> push devs to create new Exception type just to catch them, because this is
>> the only way we have.
>>
>
> This is a different issue to whether or not we have the syntax to catch
> multiple exceptions with a single catch block.
>
>> If I understand properly your pull request, the compiler will be
>> duplicating catch block ? If it is the case, would it be possible to use
>> static if to use type specific stuff of E1, E2 or E3, depending on which
>> one we are facing ?
>>
>
> No, it just creates stub catch blocks that jump to the real one.
> Duplicating the blocks would have weird effects on things like static
> variables.  I think that kind of code duplication is better done with
> something that works like mixing in case statements.
>
> catch(auto e : E1, E2) { body; }
> ->
>
> catch(E1 e)
> {
>    goto catchE2;
> }
> catch(E2 e)
> {
> catchE2:
>    body;
> }
>
>

Wow, it didn't got that. This is nice, but then, the Exception type is completely lost.

It does means that we are not interested in the Exception type, but of its presence, and so, maybe we just have created useless Exception types and this has to be fixed instead of the language ?

"Daniel Murphy" <yebblies@nospamgmail.com> wrote:
> "deadalnix" <deadalnix@gmail.com> wrote in message news:jiagbg$liu$1@digitalmars.com...
>> Le 25/02/2012 07:26, Daniel Murphy a Ècrit :
>>> https://github.com/D-Programming-Language/dmd/pull/738
>> 
>> I do think this approach have a flaw. If we go in that direction, then it push devs to create new Exception type just to catch them, because this is the only way we have.
>> 
> 
> This is a different issue to whether or not we have the syntax to catch multiple exceptions with a single catch block.
> 
>> If I understand properly your pull request, the compiler will be duplicating catch block ? If it is the case, would it be possible to use static if to use type specific stuff of E1, E2 or E3, depending on which one we are facing ?
>> 
> 
> No, it just creates stub catch blocks that jump to the real one. Duplicating the blocks would have weird effects on things like static variables.  I think that kind of code duplication is better done with something that works like mixing in case statements.
> 
> catch(auto e : E1, E2) { body; }
> ->
> 
> catch(E1 e)
> {
>   goto catchE2;
> }
> catch(E2 e)
> {
> catchE2:
>   body;
> }

Won't work unless the compiler enforce that 'body' does not use code which
requires typeof(e) == E2.

On Saturday, February 25, 2012 07:29:01 Kevin Cox wrote:
> I think there should also be multiple catches so that you can deal with different exceptions different ways without trying to upcast them over and over again.

You can do that now. Just catch each specific exception type that you want to catch. The issue is when you want to catch a specific set of exceptions and treat them all the same, but you don't want to treat all exceptions of their common type the same.

catch(e : UTFException, UnicodeException)
{
}
catch(StringException e)
{
}
catch(Exception e)
{
}

Presently, the only common type that UTFException and UnicodeException share is Exception. So, if we didn't have a syntax like I use above (which we currently don't have), if either have to catch UTFException and UnicodeException separately and duplicate the code within the catch block for each of them (though you could use a mixin or a function to reduce the duplication), or you'd have to catch Exception, and then do something like

catch(Exception e)
{
    if(cast(UTFException)e || cast(UnicodeException)e)
    {
    }
    else if(cast(StringException)e)
    {
    }
    else
    {
    }
}

That's far uglier and is completely unable to take advantage of catch's ability to catch by type. Also, what if you didn't really want to catch Exception? e.g.

catch(e : UTFException, UnicodeException)
{
}
catch(StringException e)
{
}

Then, if you went to catch Exception, because it was the common type, you'd have to rethrow the exception if it wasn't one of the 3 that you cared about, which resets the stack trace.

_That_ is the problem that this is trying to solve. If you really want to catch exceptions individulally by their specific types, then you can already do that just fine.

- Jonathan M Davis

"kennytm" <kennytm@gmail.com> wrote in message news:1711314076351895446.251635kennytm-gmail.com@news.digitalmars.com...
>>
>> catch(auto e : E1, E2) { body; }
>> ->
>>
>> catch(E1 e)
>> {
>>   goto catchE2;
>> }
>> catch(E2 e)
>> {
>> catchE2:
>>   body;
>> }
>
> Won't work unless the compiler enforce that 'body' does not use code which
> requires typeof(e) == E2.

Ok, I oversimplified it a bit.  It's more like this:

__set_except_list();
trybody();
goto __try_break;
__exceptionE1:
goto __exceptionE2;
__exceptionE2:
catchbody();
goto __try_break;
__try_break:

And when semantic is run on catchbody, the type of the variable is set to the common supertype of all the exceptions in the list.

"deadalnix" <deadalnix@gmail.com> wrote in message news:jib71o$1v05
>
> Wow, it didn't got that. This is nice, but then, the Exception type is completely lost.
>
> It does means that we are not interested in the Exception type, but of its presence, and so, maybe we just have created useless Exception types and this has to be fixed instead of the language ?

I don't expect to solve every issue with exceptions with this patch.

The main use is for when a set of different exceptions need to be handled the same way, but the common supertype includes other exceptions you don't want to catch.

Eg. you might want to catch three types of FileException and two types of SocketException and do some common error handling, but don't want to catch _every_ type of either, or the entire IOException tree.  If you want to access specific data from a subclass, make a different catch block for it, or downcast.

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?