On Sun, Feb 19, 2012 at 1:11 PM, Alex Rønne Petersen <[email protected]> wrote: > On 19-02-2012 16:00, Jose Armando Garcia wrote: >> >> 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 > > > 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
