The Right Approach to Exceptions

[Jose Armando Garcia]

On Sun, Feb 19, 2012 at 1:08 PM, Daniel Murphy <yebblies at nospamgmail.com> wrote:
> 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.
>

Quoting the source of all Java truth ;):
http://docs.oracle.com/javase/6/docs/api/java/lang/Throwable.html

I can't keep all this language semantic straight but it is my
understanding that throw vs throw e is C++ and C# thing.

In Java if you want to reset the stack you need to create a new
exception and chain the old one:

try {
  ...
} catch (Exception e) {
  throw new Exception(e);
}

> "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
>
>