The Right Approach to Exceptions

[Jose Armando Garcia]

On Sun, Feb 19, 2012 at 1:11 PM, Alex Rønne Petersen
<xtzgzorex at gmail.com> wrote:
> 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...).
>

Unless you want the Exception object to be immutable which I think it should be.

> --
> - Alex