In Java and C++, I can do something to the effect of:

try
{
    //Some code
}
catch (Exception1)
{
}
catch (Exception2)
{
}
//etc...

However, this doesn't seem to be possible in D. What is the idiom for handling a case where multiple exceptions of different types may be thrown?

> What is the idiom for handling
> a case where multiple exceptions of different types may be thrown?

I think you could catch a common baseclass like Exception and test if it's a specific Exception by casting.

On Monday, 30 January 2012 at 14:37:19 UTC, Jared wrote:
> In Java and C++, I can do something to the effect of:

That works in D too.

I believe it does it linearly though, so it will use the
first catch that matches.

try {}
catch (Exception e) {} // most throwable objects derive from Exception
catch (SpecialException e) {} // never used, because Exception matches it all



Try putting the more specific catches first, and the generic
base classes at the end of the list.

I suppose that works, though it does seem a little hackish (and I'm pretty sure it's considered bad form in Java). What was the line of reasoning for omitting this (to me, at least) extremely useful construct?

30.01.2012 16:37, Jared пишет:
> However, this doesn't seem to be possible in D.
Why not?

import std.stdio;

class Exception1 : Throwable { this( string s ) { super( s ); } }
class Exception2 : Throwable { this( string s ) { super( s ); } }

void foo() {
    throw new Exception1( "foo" );
}

void bar() {
    throw new Exception2( "bar" );
}

int main() {
    enum tryBar = false;

    try {
        static if( tryBar ) {
            bar();
        } else {
            foo();
        }
    } catch( Exception1 e1 ) {
        writeln( "First catch block: ", e1.msg );
    } catch( Exception2 e2 ) {
        writeln( "Second catch block: ", e2.msg );
    }

    return 0;
}

On 30-01-2012 15:37, Jared wrote:
> In Java and C++, I can do something to the effect of:
>
> try
> {
>      //Some code
> }
> catch (Exception1)
> {
> }
> catch (Exception2)
> {
> }
> //etc...
>
> However, this doesn't seem to be possible in D. What is the idiom for handling
> a case where multiple exceptions of different types may be thrown?

Huh? I do this several places in my code. Works For Me (TM).

- Alex

On Monday, 30 January 2012 at 14:50:23 UTC, Adam D. Ruppe wrote:
> On Monday, 30 January 2012 at 14:37:19 UTC, Jared wrote:
>> In Java and C++, I can do something to the effect of:
>
> That works in D too.
>
> I believe it does it linearly though, so it will use the
> first catch that matches.
>
> try {}
> catch (Exception e) {} // most throwable objects derive from Exception
> catch (SpecialException e) {} // never used, because Exception matches it all
>
>
>
> Try putting the more specific catches first, and the generic
> base classes at the end of the list.

To me this seems like a mistake. Since likely your catching the current exception and not one of the previously stored ones; A codepath like that should either:

A) Fail at compile time, hopefully telling you a suggested order so there's no problems.

B) Reorder the catch blocks on it's own during compile time, since only one can get caught at a time anyways.

At least that's how I see it.

On 1/30/12, Era Scarecrow <rtcvb32@yahoo.com> wrote:
> To me this seems like a mistake.

You could throw SpecialException in the handler for Exception. So it's legal code.

On Monday, 30 January 2012 at 17:17:46 UTC, Andrej Mitrovic wrote:
> On 1/30/12, Era Scarecrow <rtcvb32@yahoo.com> wrote:
>> To me this seems like a mistake.
>
> You could throw SpecialException in the handler for Exception. So it's
> legal code.

Yes, thanks to inheritance it is legal code. However it's almost the same as this, which is legal code too.

try {
} catch (Throwable t) {

} catch {Exception e) { //never executed

} catch (StreamException st) { //never executed

} //and the list can go on forever.

See the problem? Everything that COULD be caught by exception is now caught by throwable since it's inherited. At the very least the compiler should warn you that certain sections won't be executed, But then I would have to manually look up the relationships when the compiler already knows them. In GCC known code blocks that are never executed aren't even compiled in. If the compiler reorders the blocks for you, the above would become this.

try {
} catch (StreamException st) { //specific case

} catch {Exception e) { //less specific but no other inheritances of this kind

} catch (Throwable t) { //everything else.

}

On Monday, 30 January 2012 at 18:23:56 UTC, Era Scarecrow wrote:
> try {
> } catch (Throwable t) {
>
> } catch {Exception e) { //never executed
>
> } catch (StreamException st) { //never executed
>
> } //and the list can go on forever.
>
> See the problem?

No?

Error: catch at test.d(3) hides catch at test.d(4)

The compiler does not reorder the exceptions because it enforces order in the written code. As you say the compiler knows the relationship, the one reading it may not.