On 3/30/2011 10:51 AM, Sean Kelly wrote:
> On Mar 30, 2011, at 10:47 AM, Sean Kelly wrote:
> 
>> On Mar 30, 2011, at 12:29 AM, Don Clugston wrote:
>>
>>> On 30 March 2011 08:02, Brad Roberts <braddr at puremagic.com> wrote:
>>>>
>>>>
>>>> I just pushed a change set to the tests that make the TdplExceptionChaining the only code paths for test4.d and eh.d. eh.d doesn't currently pass, but I figured trading the test4.d failure for the eh.d failure was a step in the right direction.
>>>
>>> Note that the tests in eh.d are tough. It's currently failing the
>>> simplest one. Sean, you might want to take a close look at the tests,
>>> and also at the comments in deh.d
>>> The thing that's difficult is that you can have multiple chains of
>>> exceptions in flight at any given time. The most important feature is
>>> that chaining occurs only when the exception is handled (in a catch or
>>> finally), not when it's thrown, because this is when the collision
>>> actually happens.
>>
>> That's when chaining occurs, but it's possible I screwed up something regarding the in-flight lookup process.  I'll give it a look.
> 
> Here's the output when I run eh.d on my OSX box.  It looks like everything passed, though I'm not entirely sure about the "Never called" line:
> 

Did you update it from git and/or enable the parts versioned to only run on windows?

On Mar 30, 2011, at 10:56 AM, Brad Roberts wrote:

> On 3/30/2011 10:51 AM, Sean Kelly wrote:
>> On Mar 30, 2011, at 10:47 AM, Sean Kelly wrote:
>> 
>>> On Mar 30, 2011, at 12:29 AM, Don Clugston wrote:
>>> 
>>>> On 30 March 2011 08:02, Brad Roberts <braddr at puremagic.com> wrote:
>>>>> 
>>>>> 
>>>>> I just pushed a change set to the tests that make the TdplExceptionChaining the only code paths for test4.d and eh.d. eh.d doesn't currently pass, but I figured trading the test4.d failure for the eh.d failure was a step in the right direction.
>>>> 
>>>> Note that the tests in eh.d are tough. It's currently failing the
>>>> simplest one. Sean, you might want to take a close look at the tests,
>>>> and also at the comments in deh.d
>>>> The thing that's difficult is that you can have multiple chains of
>>>> exceptions in flight at any given time. The most important feature is
>>>> that chaining occurs only when the exception is handled (in a catch or
>>>> finally), not when it's thrown, because this is when the collision
>>>> actually happens.
>>> 
>>> That's when chaining occurs, but it's possible I screwed up something regarding the in-flight lookup process.  I'll give it a look.
>> 
>> Here's the output when I run eh.d on my OSX box.  It looks like everything passed, though I'm not entirely sure about the "Never called" line:
>> 
> 
> Did you update it from git and/or enable the parts versioned to only run on windows?

Darnit, I didn't even check for a version switch in eh.d.  I'll update and try again.

On Mar 30, 2011, at 11:18 AM, Sean Kelly wrote:
> 
> Darnit, I didn't even check for a version switch in eh.d.  I'll update and try again.

Alright, this turned out to be an easy problem to fix.  I was nulling out the __inflight list when a catch block was entered, and I shouldn't have been.  I'm now running into an error much later on, but I don't understand the assert.  Here's the code followed by a question:


    void collideMixed()
    {
        int works = 6;
        try
        {
            try
            {
                try
                {
                    throw new Exception("e");
                }
                finally
                {
                    throw new Error("t");
                }
            }
            catch(Exception f)
            {    // Doesn't catch, because Error is chained to it.
                works += 2;
            }
        }
        catch(Error z)
        {
            works += 4;
            assert(z.msg=="t"); // Error comes first
            assert(z.next is null); // AssertError
            assert(z.bypassedException.msg == "e");
        }
        assert(works == 10);
    }


The line labeled "AssertError" is the failure point, but I'm not clear on why this assert is even here.  If an Error passes an Exception, is the Exception really not chained to the Error?  I guess that makes it easy to determine what's collateral of what, but displaying the error chain may be a tad complicated.  Assuming this is desired behavior, how should the chain(s) be displayed?

On 30 March 2011 20:52, Sean Kelly <sean at invisibleduck.org> wrote:
> On Mar 30, 2011, at 11:18 AM, Sean Kelly wrote:
>>
>> Darnit, I didn't even check for a version switch in eh.d. ?I'll update and try again.
>
> Alright, this turned out to be an easy problem to fix. ?I was nulling out the __inflight list when a catch block was entered, and I shouldn't have been. ?I'm now running into an error much later on, but I don't understand the assert. ?Here's the code followed by a question:
>
>
> ? ?void collideMixed()
> ? ?{
> ? ? ? ?int works = 6;
> ? ? ? ?try
> ? ? ? ?{
> ? ? ? ? ? ?try
> ? ? ? ? ? ?{
> ? ? ? ? ? ? ? ?try
> ? ? ? ? ? ? ? ?{
> ? ? ? ? ? ? ? ? ? ?throw new Exception("e");
> ? ? ? ? ? ? ? ?}
> ? ? ? ? ? ? ? ?finally
> ? ? ? ? ? ? ? ?{
> ? ? ? ? ? ? ? ? ? ?throw new Error("t");
> ? ? ? ? ? ? ? ?}
> ? ? ? ? ? ?}
> ? ? ? ? ? ?catch(Exception f)
> ? ? ? ? ? ?{ ? ?// Doesn't catch, because Error is chained to it.
> ? ? ? ? ? ? ? ?works += 2;
> ? ? ? ? ? ?}
> ? ? ? ?}
> ? ? ? ?catch(Error z)
> ? ? ? ?{
> ? ? ? ? ? ?works += 4;
> ? ? ? ? ? ?assert(z.msg=="t"); // Error comes first
> ? ? ? ? ? ?assert(z.next is null); // AssertError
> ? ? ? ? ? ?assert(z.bypassedException.msg == "e");
> ? ? ? ?}
> ? ? ? ?assert(works == 10);
> ? ?}
>
>
> The line labeled "AssertError" is the failure point, but I'm not clear on why this assert is even here. ?If an Error passes an Exception, is the Exception really not chained to the Error? ?I guess that makes it easy to determine what's collateral of what, but displaying the error chain may be a tad complicated. ?Assuming this is desired behavior, how should the chain(s) be displayed?

That's the idea, to preserve the full collateral information.
Out-of-order exception chaining is very confusing if you don't know
that a bypass occured.
 It's even more important since other languages do not behave this way.
I envisage displaying something like:

Error: t.
Bypassed Exception e

with the word 'Bypassed' in front of anything which was bypassed at
any level, then go to the 'next' Throwable.
Obviously a complete solution would be to do a tree display, with
indentation to give the nesting level.
But really, the cases where you need a full tree are very obscure.
It's just important to distinguish an original Error with a collateral
Exception, from an original Exception which was bypassed because an
Error happened.