Is there a way to get the current exception inside a scope(failure)? I
have a try..catch around my main loop which simply logs the caught
exception and rethrows it. I'd like to replace this with a simple scope
(failure) but I haven't found any way to access the exception causing the
unwinding.

Is there a way to get the current exception inside a scope(failure)? I
have a try..catch around my main loop which simply logs the caught
exception and rethrows it. I'd like to replace this with a simple scope
(failure) but I haven't found any way to access the exception causing the
unwinding.

If you want to see the exception, you must catch it. scope statements do not
provide access to exceptions. So, scope works great as long as you don't need
access to the exception, but if you do, you need to use try-catch blocks.
- Jonathan M Davis

Is there a way to get the current exception inside a scope(failure)? I
have a try..catch around my main loop which simply logs the caught
exception and rethrows it. I'd like to replace this with a simple scope
(failure) but I haven't found any way to access the exception causing
the unwinding.

If you want to see the exception, you must catch it. scope statements do
not provide access to exceptions. So, scope works great as long as you
don't need access to the exception, but if you do, you need to use
try-catch blocks.
- Jonathan M Davis

My understanding is that scope(failure) simply lowers to the catch block
of a try..catch, so there's no implementation obstacle to making the
exception available. Are there known syntax or correctness obstacles to
allowing something like this:
scope(failure)(Exception ex) writeln(ex.msg);

My understanding is that scope(failure) simply lowers to the catch block
of a try..catch, so there's no implementation obstacle to making the
exception available. Are there known syntax or correctness obstacles to
allowing something like this:
scope(failure)(Exception ex) writeln(ex.msg);

Yes. It lowers to a try-catch block, but that's effectively an implementation
detail. As it stands, technically speaking, a compiler could probably
implement it without any lowering whatsoever (I don't think that the spec says
anything about how it's implemented). But even if the compiler has to use
lowering, the main problem with your suggestion is that in complicates how
scope statements work, since then it's only going to be run if the exception
type being caught matches what was being thrown, whereas right now
scope(failure) statements run on all exceptions regardless. And scope
statements aren't really meant for exception handling. Rather, they're
intended for providing a clean means of making code exception-safe. So, I
suspect that what you suggest would be rejected, but I don't know. You can
certainly create an enhancement request for it if you want to:
http://d.puremagic.com/issues
- Jonathan M Davis

Yes. It lowers to a try-catch block, but that's effectively an implementation
detail. As it stands, technically speaking, a compiler could probably
implement it without any lowering whatsoever (I don't think that the spec says
anything about how it's implemented). But even if the compiler has to use
lowering, the main problem with your suggestion is that in complicates how
scope statements work, since then it's only going to be run if the exception
type being caught matches what was being thrown, whereas right now
scope(failure) statements run on all exceptions regardless. And scope
statements aren't really meant for exception handling. Rather, they're
intended for providing a clean means of making code exception-safe. So, I
suspect that what you suggest would be rejected, but I don't know. You can
certainly create an enhancement request for it if you want to:

What about allowing catch-statements without a try-statement, something
like this:
void foo ()
{
// some code ...
catch (Exception e)
{
}
}
This would be the same as the whole function would be wrapped in a
try-statement. It's a quite handy feature that's available in Ruby.
--
/Jacob Carlborg

What about allowing catch-statements without a try-statement, something
like this:
void foo ()
{
// some code ...
catch (Exception e)
{
}
}
This would be the same as the whole function would be wrapped in a
try-statement. It's a quite handy feature that's available in Ruby.

So, you save one set of braces? I don't see how that really buys you much.
- Jonathan M Davis

So, you save one set of braces? I don't see how that really buys you much.

Yes, and the "try" keyword. It would basically be the same as allowing
to get the exception in scope(failure) but the catch-statement already
supports this.

Except that the place that scope statements go in the code is completely
different from where catch statements go. catch statements go at the end
whereas scope statements go in the middle or even the beginning so that what
you're doing in there can be close to code that corresponds to it (e.g. you
can have the code for releasing a resource right after the code for aquiring
it rather than having it in a complete separate part of the code. What you
typically do with scope statements and try-catch statements is often
fundamentally different.
I can understand wanting to be able to have access to the exception that's
flying by in a scope statement, but I really don't see how saving a try and
couple of braces adds much. Certainly, the two are completely different in
terms of what they buy you.
- Jonathan M Davis

Except that the place that scope statements go in the code is completely
different from where catch statements go. catch statements go at the end
whereas scope statements go in the middle or even the beginning so that what
you're doing in there can be close to code that corresponds to it (e.g. you
can have the code for releasing a resource right after the code for aquiring
it rather than having it in a complete separate part of the code. What you
typically do with scope statements and try-catch statements is often
fundamentally different.
I can understand wanting to be able to have access to the exception that's
flying by in a scope statement, but I really don't see how saving a try and
couple of braces adds much. Certainly, the two are completely different in
terms of what they buy you.

I've used it a couple of times in Ruby, only in very small methods. It's
not a deal breaker, it's a "nice to have" feature.
--
/Jacob Carlborg