View mode: basic / threaded / horizontal-split · Log in · Help
February 25, 2012
Re: Conclusions of the exception discussion
> 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)
February 25, 2012
Re: Conclusions of the exception discussion
"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;
}
February 25, 2012
Re: Conclusions of the exception discussion
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.
February 25, 2012
Re: Conclusions of the exception discussion
"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.
February 25, 2012
Re: Conclusions of the exception discussion
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 ?
February 25, 2012
Re: Conclusions of the exception discussion
"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.
February 25, 2012
Re: Conclusions of the exception discussion
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
February 26, 2012
Re: Conclusions of the exception discussion
"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.
February 26, 2012
Re: Conclusions of the exception discussion
"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.
February 26, 2012
Re: Conclusions of the exception discussion
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?
1 2 3
Top | Discussion index | About this forum | D home