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
