The Right Approach to Exceptions

[Alex Rønne Petersen]

On 19-02-2012 16:00, Jose Armando Garcia wrote:
> 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

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