www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Should masked exceptions be an error?

reply 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
next sibling parent "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
prev sibling next sibling parent reply 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
parent reply 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
parent 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
prev sibling next sibling parent reply "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
parent reply "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
parent "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
prev sibling next sibling parent reply 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
parent 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
prev sibling next sibling parent 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
prev sibling parent reply 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
next sibling parent "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
prev sibling next sibling parent reply "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
parent 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
prev sibling parent 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