On 19-02-2012 16:00, Jose Armando Garcia wrote:
On Sun, Feb 19, 2012 at 12:44 PM, Alex Rønne Petersen
<[email protected]> wrote:
On 19-02-2012 15:41, Andrei Alexandrescu wrote:
On 2/19/12 7:31 AM, Timon Gehr wrote:
On 02/19/2012 09:26 AM, H. S. Teoh wrote:
On Sat, Feb 18, 2012 at 11:52:00PM -0800, Jonathan M Davis wrote:
[...]
So, while at first glance, it seems like a good idea, I think that it
has too many issues as-is to work. It might be possible to adjust the
idea to make it workable though. Right now, it's possible to do it via
mixins or calling a function inside the catch, but doing something
similar to this would certainly be nice, assuming that we could sort
out the kinks.
[...]
I have an idea. What about "signature constraints" for catch, ala
template signature constraints? Something like this:
try {
...
} catch(IOException e)
if (e.errno in subsetYouWantToHandle)
{
...
}
Just using IOException as an example. The idea is to allow arbitrary
expressions in the constraint so whatever doesn't satisfy the constraint
will be regarded as "not caught", even if the base type matches.
T
Nice.
That helps. This quite nicely illustrates that types don't necessarily
need to proliferate. Something not much more constraining can be done
today:
try {
...
} catch(IOException e)
{
if (e.errno !in subsetYouWantToHandle) throw e;
...
}
Andrei
As I pointed out on the pull request, this is *evil*. It resets the stack
trace.
What? Is there a technical reason why throw resets the stack? Java
doesn't work this way. In java the stack is created when the object
Throwable is created:
"A throwable contains a snapshot of the execution stack of its thread
at the time it was created. It can also contain a message string that
gives more information about the error. Finally, it can contain a
cause: another throwable that caused this throwable to get thrown. The
cause facility is new in release 1.4. It is also known as the chained
exception facility, as the cause can, itself, have a cause, and so on,
leading to a "chain" of exceptions, each caused by another. "
We should consider changing this to work more like Java. This allows
for patterns like:
// Log the stack but don't throw
auto e = new Exception();
writefln(e.stack);
Thanks,
-Jose
--
- Alex
If Java really works that way, I'm sorry, but that just makes me think
even worse of the language/VM.
If you create an exception object in some utility function (or chain of
such), you don't want those in your stack trace. You want the stack
trace to start from where you throw the object, not where you created
it. Anything else is just confusing (and perhaps explains the several
hundred lines long stack traces Java programs sometimes spit out...).
--
- Alex
