Re: Place Assert in Exception
On Oct 10, 7:14 pm, "Daniel T." <danie...@earthlink.net> wrote:
James Kanze <james.ka...@gmail.com> wrote:
"Daniel T." <danie...@earthlink.net> wrote:
Immortal Nephi <Immortal_Ne...@hotmail.com> wrote:
Please tell me what you think Error_Report class? Is throw
better than abort()?
If you are writing a library that others will be using, then
it is not up to you to decide to summarily abort their app.
Yes and no. If they violate the contract of your library,
summarily terminating their application is probably the best
solution (in most applications).
Again, I don't see where that is up to you since you are not
the application writer and you don't know if the particular
application that your library is being used in qualifies under
the phrase "most applications" or if this particular situation
is a special case.
Yes. The ideal case is to use a callback, which defaults to
aborting. But few libraries, starting with the standard
library, do. The usual convention is to say that contract
violations are undefined behavior---the the client code simply
doesn't have the right to violate the contract, and if he does,
he gets whatever you decide to give him.
Note that in the same way, as a library writer, you don't know
that the application is prepared to handle such exceptions, so
by the same argument that you use against aborting, you can't
throw an exception either.
Note that assert is never used by the standard library;
Really? It is in the implementations I'm familiar with.
Anytime the library detects you've done something that the
standard specifies is undefined behavior.
Asserts may very well be used in particular implementations of
the standard library, where the standard doesn't specify the
result of an operation, but the standard itself never
specifies that doing X will cause an assert to fire, but it
does make such specifications about exceptions.
Yes. Exceptions are part of the contract. You can count on
them. Undefined behavior is not part of the contract, and the
standard doesn't want to impose on an implementation the cost of
verifying it. In practice, all implementations which do verify
it trigger an assertion failure. (Of course, under Windows, you
can configure things so that an assertion failure results in an
exception. If yours is one of the rare applications where that
is more appropriate.)
--
James Kanze