digitalmars.D - Should masked exceptions be an error?

Andrei Alexandrescu (13/13) Nov 23 2009 Consider:

Denis Koroskin (3/16) Nov 24 2009 Think so, too.
Ary Borenszweig (2/20) Nov 24 2009 Yes, it works like that in Java.

Michal Minich (1/21) Nov 24 2009 Yes, it works like that in C#.

Ary Borenszweig (2/27) Nov 24 2009 Yes, it works like that in D.

Lars T. Kyllingstad (5/23) Nov 24 2009 Definitely. I think the spec should state as a general rule that

Nick Sabalausky (5/7) Nov 24 2009 Disagree very much with this. I don't want to have to carefully comment ...

Denis Koroskin (2/11) Nov 24 2009 More or less I agree. That's what -w option is for.

Walter Bright (15/16) Nov 24 2009 =================================

Andrei Alexandrescu (3/23) Nov 24 2009 Great! Sorry, I don't have access to dmd.

Rory McGuire (9/28) Nov 24 2009 Yes, I think so too.
Brad Roberts (4/21) Nov 24 2009 Alternate thought.. should order matter or should it automatically sort

Steven Schveighoffer (6/28) Nov 24 2009 If this is possible, it makes the most sense to me. I don't see how it'...
Nick Sabalausky (10/32) Nov 24 2009 Use first match:

Andrei Alexandrescu (4/32) Nov 24 2009 + needs no work

Walter Bright (3/6) Nov 24 2009 I think the user should know if one inherits from the other, so I'm

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

Consider:

try {
    ...
} catch (Exception) {
    ...
} catch (StdioException) {
    ...
}

The second handler never matches because StdioException is a subclass of 
Exception, so the first handler will always match whatever the second 
matches.

Should that be a compile-time error? I think so.


Andrei

Nov 23 2009

"Denis Koroskin" <2korden gmail.com> writes:

On Tue, 24 Nov 2009 10:30:30 +0300, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:

 Consider:

 try {
     ...
 } catch (Exception) {
     ...
 } catch (StdioException) {
     ...
 }

 The second handler never matches because StdioException is a subclass of  
 Exception, so the first handler will always match whatever the second  
 matches.

 Should that be a compile-time error? I think so.


 Andrei

Think so, too.

Nov 24 2009

Ary Borenszweig <ary esperanto.org.ar> writes:

Andrei Alexandrescu wrote:
 Consider:
 
 try {
    ...
 } catch (Exception) {
    ...
 } catch (StdioException) {
    ...
 }
 
 The second handler never matches because StdioException is a subclass of 
 Exception, so the first handler will always match whatever the second 
 matches.
 
 Should that be a compile-time error? I think so.
 
 
 Andrei

Yes, it works like that in Java.

Nov 24 2009

Michal Minich <michal.minich gmail.com> writes:

 Andrei Alexandrescu wrote:
 
 Consider:
 
 try {
 ...
 } catch (Exception) {
 ...
 } catch (StdioException) {
 ...
 }
 The second handler never matches because StdioException is a subclass
 of Exception, so the first handler will always match whatever the
 second matches.
 
 Should that be a compile-time error? I think so.
 
 Andrei
 

 Yes, it works like that in Java.

Nov 24 2009

Ary Borenszweig <ary esperanto.org.ar> writes:

Michal Minich wrote:
 Andrei Alexandrescu wrote:

 Consider:

 try {
 ...
 } catch (Exception) {
 ...
 } catch (StdioException) {
 ...
 }
 The second handler never matches because StdioException is a subclass
 of Exception, so the first handler will always match whatever the
 second matches.

 Should that be a compile-time error? I think so.

 Andrei

 Yes, it works like that in Java.

 
 

 
 

Yes, it works like that in D.

Nov 24 2009

"Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:

Andrei Alexandrescu wrote:
 Consider:
 
 try {
    ...
 } catch (Exception) {
    ...
 } catch (StdioException) {
    ...
 }
 
 The second handler never matches because StdioException is a subclass of 
 Exception, so the first handler will always match whatever the second 
 matches.
 
 Should that be a compile-time error? I think so.
 
 
 Andrei


Definitely. I think the spec should state as a general rule that 
unreachable code is an error. Then more such checks can be added to DMD 
even after D2 is declared stable.

-Lars

Nov 24 2009

"Nick Sabalausky" <a a.a> writes:

"Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> wrote in message 
news:heg9jk$7f3$1 digitalmars.com...
 I think the spec should state as a general rule that unreachable code is 
 an error.

Disagree very much with this. I don't want to have to carefully comment out 
temporarily-dead code when I'm inserting debugging breaks and returns. 
That'd be a real PITA.

Nov 24 2009

"Denis Koroskin" <2korden gmail.com> writes:

On Tue, 24 Nov 2009 18:31:27 +0300, Nick Sabalausky <a a.a> wrote:

 "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> wrote in message
 news:heg9jk$7f3$1 digitalmars.com...
 I think the spec should state as a general rule that unreachable code is
 an error.

 Disagree very much with this. I don't want to have to carefully comment  
 out
 temporarily-dead code when I'm inserting debugging breaks and returns.
 That'd be a real PITA.

More or less I agree. That's what -w option is for.

Nov 24 2009

Walter Bright <newshound1 digitalmars.com> writes:

Andrei Alexandrescu wrote:
 Should that be a compile-time error? I think so.

=================================
class A : Exception
{
     this(string msg) { super(msg); }
}

void foo()
{
     try { }
     catch (Exception e) { }
     catch (A e) { }
}
=================================

gives:

test.d(9): Error: catch at test.d(10) hides catch at test.d(11)

Nov 24 2009

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

Walter Bright wrote:
 Andrei Alexandrescu wrote:
 Should that be a compile-time error? I think so.

 
 =================================
 class A : Exception
 {
     this(string msg) { super(msg); }
 }
 
 void foo()
 {
     try { }
     catch (Exception e) { }
     catch (A e) { }
 }
 =================================
 
 gives:
 
 test.d(9): Error: catch at test.d(10) hides catch at test.d(11)

Great! Sorry, I don't have access to dmd.

Andrei.

Nov 24 2009

Rory McGuire <rjmcguire gmail.com> writes:

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:
 
 Consider:
 
 try {
     ...
 } catch (Exception) {
     ...
 } catch (StdioException) {
     ...
 }
 
 The second handler never matches because StdioException is a subclass of 
 Exception, so the first handler will always match whatever the second 
 matches.
 
 Should that be a compile-time error? I think so.
 
 
 Andrei
 

Yes, I think so too.

And shouldn't the following also produce a compile-time error?

void main() {
	try {

	} catch (Exception e) {

	}
}

Nov 24 2009

Brad Roberts <braddr bellevue.puremagic.com> writes:

On Mon, 23 Nov 2009, Andrei Alexandrescu wrote:

 Consider:
 
 try {
    ...
 } catch (Exception) {
    ...
 } catch (StdioException) {
    ...
 }
 
 The second handler never matches because StdioException is a subclass of
 Exception, so the first handler will always match whatever the second matches.
 
 Should that be a compile-time error? I think so.
 
 
 Andrei

Alternate thought.. should order matter or should it automatically sort 
such that most specific catch is preferred.  Sort of matches the 
declaration order doesn't (ok, shouldn't) matter philosophy.

Nov 24 2009

"Steven Schveighoffer" <schveiguy yahoo.com> writes:

On Tue, 24 Nov 2009 16:20:14 -0500, Brad Roberts  
<braddr bellevue.puremagic.com> wrote:

 On Mon, 23 Nov 2009, Andrei Alexandrescu wrote:

 Consider:

 try {
    ...
 } catch (Exception) {
    ...
 } catch (StdioException) {
    ...
 }

 The second handler never matches because StdioException is a subclass of
 Exception, so the first handler will always match whatever the second  
 matches.

 Should that be a compile-time error? I think so.


 Andrei

 Alternate thought.. should order matter or should it automatically sort
 such that most specific catch is preferred.  Sort of matches the
 declaration order doesn't (ok, shouldn't) matter philosophy.

If this is possible, it makes the most sense to me.  I don't see how it's  
not possible, since inheritance trees cannot have cycles, and therefore  
should always be sortable.

-Steve

Nov 24 2009

"Nick Sabalausky" <a a.a> writes:

"Brad Roberts" <braddr bellevue.puremagic.com> wrote in message 
news:alpine.DEB.2.00.0911241319190.18188 bellevue.puremagic.com...
 On Mon, 23 Nov 2009, Andrei Alexandrescu wrote:

 Consider:

 try {
    ...
 } catch (Exception) {
    ...
 } catch (StdioException) {
    ...
 }

 The second handler never matches because StdioException is a subclass of
 Exception, so the first handler will always match whatever the second 
 matches.

 Should that be a compile-time error? I think so.


 Andrei

 Alternate thought.. should order matter or should it automatically sort
 such that most specific catch is preferred.  Sort of matches the
 declaration order doesn't (ok, shouldn't) matter philosophy.

Use first match:
+ Consistent with "else if"

Use most specific match:
+ Consistent with template pattern matching
+ Possibly more practical
- I can just imagine all the bugs this would probably have in DMD

Personally, I'm torn. I'd probably lean more towards "most specific match", 
but I'd be perfectly happy either way.

Nov 24 2009

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

Nick Sabalausky wrote:
 "Brad Roberts" <braddr bellevue.puremagic.com> wrote in message 
 news:alpine.DEB.2.00.0911241319190.18188 bellevue.puremagic.com...
 On Mon, 23 Nov 2009, Andrei Alexandrescu wrote:

 Consider:

 try {
    ...
 } catch (Exception) {
    ...
 } catch (StdioException) {
    ...
 }

 The second handler never matches because StdioException is a subclass of
 Exception, so the first handler will always match whatever the second 
 matches.

 Should that be a compile-time error? I think so.


 Andrei

 Alternate thought.. should order matter or should it automatically sort
 such that most specific catch is preferred.  Sort of matches the
 declaration order doesn't (ok, shouldn't) matter philosophy.

 
 Use first match:
 + Consistent with "else if"

+ needs no work

:o)

Andrei

Nov 24 2009

Walter Bright <newshound1 digitalmars.com> writes:

Brad Roberts wrote:
 Alternate thought.. should order matter or should it automatically sort 
 such that most specific catch is preferred.  Sort of matches the 
 declaration order doesn't (ok, shouldn't) matter philosophy.

I think the user should know if one inherits from the other, so I'm 
reluctant to try and hide it by sorting.

Nov 24 2009

D Programming

C/C++ Programming

Other

digitalmars.D - Should masked exceptions be an error?