Exception/Error division in D

Jonathan M Davis jmdavisProg at gmx.com
Fri Jun 1 12:49:09 PDT 2012


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


More information about the Digitalmars-d mailing list