On Sun, Feb 19, 2012 at 1:08 PM, Daniel Murphy <[email protected]> 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" <[email protected]> wrote in message > news:[email protected]... > 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 > >
