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

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.

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.

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

> 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 C#.

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)

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) {

	}
}

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 C#.
> 
> 

Yes, it works like that in D.

"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.

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.