Jump to page: 1 2
Thread overview
[D-runtime] [D-Programming-Language/druntime] 1117e5: implemented proper exception chaining on Posix
Mar 28, 2011
Sean Kelly
Mar 29, 2011
Don Clugston
Mar 29, 2011
Sean Kelly
Mar 29, 2011
Don Clugston
Mar 29, 2011
Sean Kelly
Mar 30, 2011
Brad Roberts
Mar 30, 2011
Don Clugston
Mar 30, 2011
Sean Kelly
Mar 30, 2011
Sean Kelly
Mar 30, 2011
Brad Roberts
Mar 30, 2011
Sean Kelly
Mar 30, 2011
Sean Kelly
Mar 30, 2011
Don Clugston
March 28, 2011
Branch: refs/heads/master
Home:   https://github.com/D-Programming-Language/druntime

Commit: 1117e5f20adc14f9d147d47a757e5b20060c0ddb
    https://github.com/D-Programming-Language/druntime/commit/1117e5f20adc14f9d147d47a757e5b20060c0ddb
Author: Sean Kelly <sean at invisibleduck.org>
Date:   2011-03-28 (Mon, 28 Mar 2011)

Changed paths:
  M src/rt/deh2.d
  M src/rt/dmain2.d
  M test/gcbench/huge_single.d
  M test/gcbench/rand_large.d
  M test/gcbench/rand_small.d
  M test/gcbench/runall.d
  M test/gcbench/tree1.d
  M test/gcbench/tree2.d

Log Message:
-----------
implemented proper exception chaining on Posix


March 28, 2011
These changes should bring Posix exception chaining in line with Windows.  The basic rule is that when a new (non-Error) Throwable T is thrown past an in-flight Throwable F it is replaced by F and appended to F's chain.  If T is an Error then F is appended to T's chain and T continues to meander up the stack.  I wasn't sure what to do if both T and F were of type Error, so I stuck to the aforementioned rule for now.  I've tested this for a few moderately complex cases, but haven't gotten really fancy with nested exception generation.  Hopefully the test suite will prove things out further.
March 29, 2011
Excellent!
The rule I used on Windows is that chaining goes in historical order
(the first Error stays as the Master exception and subsequent Errors
are chained to it). This rule applies in all cases except when an
Error is thrown when an Exception is in flight; this is ONLY time when
queue-jumping occurs.
BTW the DMD test suite has some harsh tests for exception chaining,
they are enabled only for Windows at the moment.
set version  = TdplExceptionChaining in:
test/runnable/eh.d
See also
test/runnable/test4.d


On 29 March 2011 00:09, Sean Kelly <sean at invisibleduck.org> wrote:
> These changes should bring Posix exception chaining in line with Windows. ?The basic rule is that when a new (non-Error) Throwable T is thrown past an in-flight Throwable F it is replaced by F and appended to F's chain. ?If T is an Error then F is appended to T's chain and T continues to meander up the stack. ?I wasn't sure what to do if both T and F were of type Error, so I stuck to the aforementioned rule for now. ?I've tested this for a few moderately complex cases, but haven't gotten really fancy with nested exception generation. ?Hopefully the test suite will prove things out further.
> _______________________________________________
> D-runtime mailing list
> D-runtime at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/d-runtime
>
March 29, 2011
Thanks!  I'll make sure the Posix implementation passes the tests today, then submit a pull request to remove the version flag.

On Mar 28, 2011, at 5:18 PM, Don Clugston wrote:

> Excellent!
> The rule I used on Windows is that chaining goes in historical order
> (the first Error stays as the Master exception and subsequent Errors
> are chained to it). This rule applies in all cases except when an
> Error is thrown when an Exception is in flight; this is ONLY time when
> queue-jumping occurs.
> BTW the DMD test suite has some harsh tests for exception chaining,
> they are enabled only for Windows at the moment.
> set version  = TdplExceptionChaining in:
> test/runnable/eh.d
> See also
> test/runnable/test4.d
> 
> 
> On 29 March 2011 00:09, Sean Kelly <sean at invisibleduck.org> wrote:
>> These changes should bring Posix exception chaining in line with Windows.  The basic rule is that when a new (non-Error) Throwable T is thrown past an in-flight Throwable F it is replaced by F and appended to F's chain.  If T is an Error then F is appended to T's chain and T continues to meander up the stack.  I wasn't sure what to do if both T and F were of type Error, so I stuck to the aforementioned rule for now.  I've tested this for a few moderately complex cases, but haven't gotten really fancy with nested exception generation.  Hopefully the test suite will prove things out further.
>> _______________________________________________
>> D-runtime mailing list
>> D-runtime at puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/d-runtime
>> 
> _______________________________________________
> D-runtime mailing list
> D-runtime at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/d-runtime

March 29, 2011
On 29 March 2011 16:21, Sean Kelly <sean at invisibleduck.org> wrote:
> Thanks! ?I'll make sure the Posix implementation passes the tests today, then submit a pull request to remove the version flag.

DMD is currently failing test4.d on everything except Windows. That's a good sign! But it means that test4 should be modified immediately (version = TdplExceptionChaining should be defined on all platforms, not just Windows).
March 29, 2011
On Mar 29, 2011, at 1:17 PM, Don Clugston wrote:

> On 29 March 2011 16:21, Sean Kelly <sean at invisibleduck.org> wrote:
>> Thanks!  I'll make sure the Posix implementation passes the tests today, then submit a pull request to remove the version flag.
> 
> DMD is currently failing test4.d on everything except Windows. That's a good sign! But it means that test4 should be modified immediately (version = TdplExceptionChaining should be defined on all platforms, not just Windows).

Okay... the latest revision passes test4 on Posix with version=TdplExceptionChaining defined.  Does someone with DMD commit access want to modify the file manually or should I submit a pull request?

March 29, 2011
On 3/29/2011 3:42 PM, Sean Kelly wrote:
> On Mar 29, 2011, at 1:17 PM, Don Clugston wrote:
> 
>> On 29 March 2011 16:21, Sean Kelly <sean at invisibleduck.org> wrote:
>>> Thanks!  I'll make sure the Posix implementation passes the tests today, then submit a pull request to remove the version flag.
>>
>> DMD is currently failing test4.d on everything except Windows. That's a good sign! But it means that test4 should be modified immediately (version = TdplExceptionChaining should be defined on all platforms, not just Windows).
> 
> Okay... the latest revision passes test4 on Posix with version=TdplExceptionChaining defined.  Does someone with DMD commit access want to modify the file manually or should I submit a pull request?

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.

Later,
Brad

March 30, 2011
On 30 March 2011 08:02, Brad Roberts <braddr at puremagic.com> wrote:
> On 3/29/2011 3:42 PM, Sean Kelly wrote:
>> On Mar 29, 2011, at 1:17 PM, Don Clugston wrote:
>>
>>> On 29 March 2011 16:21, Sean Kelly <sean at invisibleduck.org> wrote:
>>>> Thanks! ?I'll make sure the Posix implementation passes the tests today, then submit a pull request to remove the version flag.
>>>
>>> DMD is currently failing test4.d on everything except Windows. That's a good sign! But it means that test4 should be modified immediately (version = TdplExceptionChaining should be defined on all platforms, not just Windows).
>>
>> Okay... the latest revision passes test4 on Posix with version=TdplExceptionChaining defined. ?Does someone with DMD commit access want to modify the file manually or should I submit a pull request?
>
> 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.
March 30, 2011
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.
March 30, 2011
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:


sean$ eh
start
try 1
finally 1
try 1
finally 1
try 2
done
foo
i = 0
catch, i = 0
i = 1
catch, i = 1
i = 2
catch, i = 2
i = 3
catch, i = 3
i = 4
catch, i = 4
i = 5
catch, i = 5
i = 6
catch, i = 6
i = 7
catch, i = 7
i = 8
catch, i = 8
i = 9
catch, i = 9
foo
i = 0
catch, i = 0
i = 1
catch, i = 1
i = 2
catch, i = 2
i = 3
catch, i = 3
i = 4
catch, i = 4
i = 5
catch, i = 5
i = 6
catch, i = 6
i = 7
catch, i = 7
i = 8
catch, i = 8
i = 9
catch, i = 9
iterations 10 totals: 10, 0
a
--
tb
b
Starting test
object.Exception at eh.d(170): test1
----------------
5   eh                                  0x00002acb void eh.test4() + 159
6   eh                                  0x0000253b _Dmain + 59
7   eh                                  0x0001334b extern (C) int rt.dmain2.main(int, char**).void runMain() + 23
8   eh                                  0x000132d2 extern (C) int rt.dmain2.main(int, char**).void tryExec(scope void delegate()) + 38
9   eh                                  0x00013393 extern (C) int rt.dmain2.main(int, char**).void runAll() + 59
10  eh                                  0x000132d2 extern (C) int rt.dmain2.main(int, char**).void tryExec(scope void delegate()) + 38
11  eh                                  0x00013263 main + 179
12  eh                                  0x000024f5 start + 53
initial test.
pass
object.Exception at eh.d(198): test2
----------------
5   eh                                  0x00002d60 void eh.test4().void __dgliteral1() + 100
6   eh                                  0x00002a26 void eh.Tester.stuff() + 30
7   eh                                  0x00002bad void eh.test4() + 385
8   eh                                  0x0000253b _Dmain + 59
9   eh                                  0x0001334b extern (C) int rt.dmain2.main(int, char**).void runMain() + 23
10  eh                                  0x000132d2 extern (C) int rt.dmain2.main(int, char**).void tryExec(scope void delegate()) + 38
11  eh                                  0x00013393 extern (C) int rt.dmain2.main(int, char**).void runAll() + 59
12  eh                                  0x000132d2 extern (C) int rt.dmain2.main(int, char**).void tryExec(scope void delegate()) + 38
13  eh                                  0x00013263 main + 179
14  eh                                  0x000024f5 start + 53
Never called.
object.Exception at eh.d(239): test3
----------------
5   eh                                  0x00002dec void eh.test4().void __dgliteral2() + 100
6   eh                                  0x00002a26 void eh.Tester.stuff() + 30
7   eh                                  0x00002c67 void eh.test4() + 571
8   eh                                  0x0000253b _Dmain + 59
9   eh                                  0x0001334b extern (C) int rt.dmain2.main(int, char**).void runMain() + 23
10  eh                                  0x000132d2 extern (C) int rt.dmain2.main(int, char**).void tryExec(scope void delegate()) + 38
11  eh                                  0x00013393 extern (C) int rt.dmain2.main(int, char**).void runAll() + 59
12  eh                                  0x000132d2 extern (C) int rt.dmain2.main(int, char**).void tryExec(scope void delegate()) + 38
13  eh                                  0x00013263 main + 179
14  eh                                  0x000024f5 start + 53
Passed!
i: 2
finally
i: 1
finally
i: 0
finally
--- tctbtaone
two
three
finish
sean$


« First   ‹ Prev
1 2