On Friday, June 01, 2012 03:29:17 Walter Bright wrote: > On 6/1/2012 1:15 AM, Jens Mueller wrote: > > Since the current implementation does not follow the specification > > regarding scope and finally block being executed in case of Error will > > try ... catch (...Error) keep working? > > No. The reason for this is the implementation was not updated after the > split between Error and Exception happened. It was overlooked. > > > I have code that uses > > assertThrows!AssertError to test some in contracts. Will this code > > break? > > I don't know exactly what your code is, but if you're relying on scope to > unwind in the presence of Errors, that will break.
std.exception.assertThrown will catch AssertErrors just fine, though I thought that it had a warning about catching non-Exceptions, and glancing at it now, it doesn't look like it does. I should probably add that. In any case, it's specifically designed so that it can catch AssertErrors, and nothing it itself does should require cleanup, but if the expression evaluated would have required cleanup, and the AssertError skipped it, then whatever program state is affected by that is now invalid. Anyone using assertThrown!AssertError is going to have to worry about that just as much as when you catch an Error yourself. However, it _is_ true that that's safer right now then it would be if scope statements, destructors, and finally blocks were no longer run for Errors, since in many, many cases, failed assertions in unit tests wouldn't really invalidate anything in the program. What's more likely to happen is that files won't get cleaned up and stuff ilke that. But the AssertError in unit tests case is really the only case that I'm aware of where I see a strong argument for having cleanup occur for Errors. - Jonathan M Davis
