The Right Approach to Exceptions

[Daniel Murphy]

Are you sure about that?

My understanding is java works the same way in terms of re-evaluating stack 
traces, except that it has
'throw;' which keeps the original intact, specifically for rethrowing.

"Jose Armando Garcia" <jsancio at gmail.com> wrote in message 
news:mailman.601.1329663665.20196.digitalmars-d at puremagic.com...
On Sun, Feb 19, 2012 at 12:44 PM, Alex Rønne Petersen
<xtzgzorex at gmail.com> 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