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
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
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
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 {}
On 1/30/12, Era Scarecrow rtcv...@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 rtcv...@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
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
On Monday, 30 January 2012 at 19:25:03 UTC, Jesse Phillips wrote:
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
On 1/30/12, Era Scarecrow rtcv...@yahoo.com wrote:
If the compiler reorders the blocks for you
A warning, maybe. But I'm against compilers which try to be too smart
and rewrite code to change its semantics. If there's something wrong
with my code I want to know about it (warning or error) and
On Tuesday, January 31, 2012 01:05:20 Andrej Mitrovic wrote:
On 1/30/12, Era Scarecrow rtcv...@yahoo.com wrote:
If the compiler reorders the blocks for you
A warning, maybe. But I'm against compilers which try to be too smart
and rewrite code to change its semantics. If there's something
Jonathan M Davis:
I do think that having the compiler complain when one catch block hides
another makes a lot of sense, but I think that that's as far as it should
go. It's the programmer's job to fix their code, not the compiler's.
I agree. Do we create a new diagnostic enhancement request
I see no reason why the compiler should be reordering anything
here. That changes the semantics of the code. It's not like
it's a great burden on the programmer to just reorder the
blocks so that they're in the correct order. Having the
compiler give a warning or error would be plenty, and a
15 matches
Mail list logo
