[D-runtime] win32 regression in exception handling

[Brad Roberts]

On 1/26/2011 8:51 AM, Jonathan M Davis wrote:
> On Wednesday 26 January 2011 04:35:13 Don Clugston wrote:
>> On 26 January 2011 12:21, Jonathan M Davis <jmdavisProg at gmx.com> wrote:
>>> On Wednesday 26 January 2011 03:02:55 Don Clugston wrote:
>>>> On 26 January 2011 11:17, Jonathan M Davis <jmdavisProg at gmx.com> wrote:
>>>>> On Wednesday 26 January 2011 01:58:50 Don Clugston wrote:
>>>>>> On 26 January 2011 10:32, Jonathan M Davis <jmdavisProg at gmx.com> wrote:
>>>>>>> How else would an error be thrown?
>>>>>>
>>>>>> In many cases, it's thrown by hardware. The exception object is
>>>>>> created long after the throw occurred.
>>>>>> There are also 'foreign' exceptions, which are thrown by (say) C++.
>>>>>>
>>>>>> (I suspect that Linux DMD can't handle any of those -- but Windows
>>>>>> DMD can).
>>>>>
>>>>> So, what exactly about that makes it a problem that the file and line
>>>>> number have default arguments? If it gives the arguments (like it
>>>>> pretty much has to be doing),
>>>>
>>>> No, it doesn't give the arguments. It has no way of knowing what they
>>>> are (in fact, they may not even exist at all).
>>>>
>>>> then it doesn't use the defaults, so they don't cause any problems
>>>>
>>>>> there. And is it only file and line number which cause problems if
>>>>> they have defaults, or is it everything (e.g. Throwable next)?
>>>>
>>>> It's only file and line number that are a problem. next will just be
>>>> null. The thing which you're maybe not understanding is that in these
>>>> cases, the exception object is created when it is caught, not when it
>>>> is thrown.
>>>
>>> Well, I certainly I have no clue about what is really going on then, and
>>> it would probably take a fair bit of discussion and/or research for me
>>> to understand. Obviously, there's stuff going on here that's at a far
>>> lower level than I'm used to dealing with.
>>
>> Yeah, it's a bit hairy. It took me a few weeks to work out what's going on.
>> There's all kinds of weird stuff, where you make function calls that
>> never return, because the stack disappears...
>> In the end, the whole thing is an elaborate illusion that gives you a
>> really nice model to program against.
>> Fortunately, all of the weirdness is confined to a very small number
>> of functions.
>>
>>> Regardless, is it all Throwables that have the problem, or is it just
>>> Throwable, Exception, and or Error? Throwable and Error really shouldn't
>>> be a problem, since programmers wouldn't normally be creating those (at
>>> most, they'd be creating objects derived from them), but you definitely
>>> lose something if Exception has the problem as well. And you
>>> _definitely_ lose something if _all_ Throwables have the problem. In any
>>> case, I need to know which ones are a problem if I'm going to fix them.
>>
>> It is only Throwable, and Error. Not anything derived from them.
>> (Really, I think both of those should eventually become abstract
>> classes anyway. Not right now, because compiler changes are required).
> 
> Well, that shouldn't be much of a problem then. I really would have expected 
> them to be abstract anyway. I'll check in a fix shortly.
> 
> - Jonathan M Davis
> _______________________________________________
> D-runtime mailing list
> D-runtime at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/d-runtime

Hrm.. the revert didn't make the problem go away:

http://d.puremagic.com/test-results/test.ghtml?runid=6631

You can see from the checkout log that the object files were updated, but from the dmd test run, the same test failed in
the same way.