Re: [boost] Proposed Boost Assert -- once again

From: Fernando Cacciola (fernando_cacciola_at_[hidden])
Date: 2002-11-14 14:06:29

----- Original Message -----
From: "Peter Dimov" <pdimov_at_[hidden]>
To: "Boost mailing list" <boost_at_[hidden]>
Sent: Thursday, November 14, 2002 1:32 PM
Subject: Re: [boost] Proposed Boost Assert -- once again

> - there is no explicit support for throwing exceptions, and no standard
> exception class is defined. (Although it is trivial to define a handler
that
> throws.) This is intentional. I don't believe that we, at Boost, want to
> encourage this particular programming practice (assertions that throw.)
>
AFAIK, the differences between abort and throw are two-fold.

On one hand, there are platform/compiler-dependent differences.
Some enviroments (mostly Unix-like) don't allow you to get context
information at the point of the throw, but, OTOH, supply a core-dump in the
case of abort(). On these enviroments, abort() is clearly superior.
Other enviroments (Windows) do allow you to get context information at the
point of the throw and do not supply a *textual* core-dump for post-morten
debugging (although you can use JIT). On this enviroment, throw is clearly
superior.

On the other hand, there are application level differences.
Some applications find much better to abort *just the current task* in case
of a library failure. In many cases, those failures are far from
catastrophic and the application can keep running normally without much
trouble.
In these applications, even during a debug session it might be useful to let
the application keep running because the programmer might need do something
else before finally aborting (such as testing other tasks or saving
documents).
This is a typical scenario with event driven applications with builtin fault
tolerance.
There are also critical applications which simply *cannot* just abort in
case of a failure.

Therefore, I conclude that there is not a unique preferable way to deal with
assertions.
On the application-level, user needs are so varied that the best we can do
is to provide a hook so that the user can do whatever she needs to do. This
role is well played by "assertion_failed()".
On the library-level, the best choice is IMO given by the target platform.
For example, if you are targeting Borland on Windows, like me, then abort()
is a very bad choice since it leaves no information whatsoever. An
exception, on the other hand, is caught by the compiler right at the throw
and I can see all I need to spot the problem.
But on most Unix-like systems, the situation is exactly the other way
around: abort() gives you a core-dump while an exception unwinds the stack
*before* you get a chance to see what happened.

Therefore, I think that a good choice would be to have a default assertion
behaviour based on the target platform.

How to supply a target-dependent default definition and at the same time
allow the user to override it easely I'm not sure. It appears that Kevin Van
Horn's proposal might suite better my criteria.

> - there is no BOOST_ASSERT_MSG. I don't have a strong opinion here. As the
> main purpose of BOOST_ASSERT is to replace the standard assert, and since
> the file/line/function supply enough information, I haven't provided a
> BOOST_ASSERT_MSG macro, but I'm not strongly opposed to having one,
either.
>
I've found additional textual information quite useful in many cases, so I'd
vote for including the _MSG variant.

Fernando Cacciola