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