Assert and the optional Message

[Jonathan M Davis]

On Saturday, March 10, 2012 16:52:43 Jacob Carlborg wrote:
> On 2012-03-09 17:56, Jonathan M Davis wrote:
> > The current implementation may not skip them, but if so, that might
> > actually be a bug. Errors are not intended to be recoverable, so you
> > can't rely on them hitting finally blocks, scope statements, or
> > destructors. They may very well do so at present. While it's not
> > guaranteed that they will, I'm not sure that it's guaranteed that they
> > _won't_. So, it may or may not be a bug if they do.
> > 
> > It was never intended that AssertError or any other Error be particularly
> > catchable, but it's also true that D is a systems programming language, so
> > it'll let you do stuff which is unsafe, so if you know what you're doing,
> > then there are circumstances where you can get away with (unit testing is
> > one example of where catching AssertErrors might make sense). But you
> > have to know what you're doing, since it's _not_ safe.
> > 
> > - Jonathan M Davis
> 
> If it's not safe to catch AssertErrors, how is the executable supposed
> to be able to continue a unit test run when an AssertError has been thrown?
> 
> I'm referring to the suggested changes that a unit test run should be
> able to continue in other modules even if an AssertError has been
> thrown. It seems to be issue 5283:
> http://d.puremagic.com/issues/show_bug.cgi?id=5283

1. Assertions are treated a bit differently in unit tests. I don't remember 
what the exact differences are at the moment (and I think that they've changed 
over time), but they're not completely normal from what I recall. So, the 
situation may or may not be somewhat different in unit tests. At minimum, they 
get left in when -unittest is used, even if -release is used, and I believe 
that they have a somewhat different handler. They probably function the same 
with regards to destructors, scope statements, and finally though.

2. As long as unit tests are properly isolated, then it's unlikely to be a big 
issue, and even if it _is_ problem, it's only a problem as long as tests are 
failing. So, while this may cause problems in some cases, it's still arguably 
worth it, since the _first_ test failure is still completely valid (as it is 
now), and the rest are _likely_ to be valid, so you'd generally be getting 
more information than before.

If it's a big enough problem, it could probably be made so that AssertErrors 
are treated differently in unit tests such that they _are_ guaranteed to hit 
destructors, scope statements, and finally. But the basic design of Errors is 
that they're supposed to be unrecoverable, so skipping all of those isn't 
generally an issue. And given that can get Errors thrown from nothrow 
functions, running them might actually do funny things in some cases, because 
the assumptions surrounding nothrow have been effectively violated.

- Jonathan M Davis