Assert vs. exceptions

[BigMan]

When should one prefer assert-ing to throwing an exception?

[Karl Heinz Buchegger]

BigMan wrote:

When should one prefer assert-ing to throwing an exception?

assert-ing is a debug-build only tool. They are not present in
release-builds, that is the program as usually shiped to the
customer.

--
Karl Heinz Buchegger
kb******@gascad .at

[ulrich]

On 13 Apr 2005 01:10:42 -0700, BigMan <Bi****@abv.b g> wrote:

When should one prefer assert-ing to throwing an exception?

assertions should protect from (not always obvious) mistakes of the
developer, e.g. using a pointer despite its being NULL.

exceptions are a way to handle errors that may legitimately occur at
runtime, e.g. the failure of trying to connect to some server (which may
not respond for various reasons).

[lilburne]

BigMan wrote:

When should one prefer assert-ing to throwing an exception?

Always assert, unless you have no other choice, but even then consider
the exception to be a design flaw to be eliminated.

[Phlip]

BigMan wrote:

When should one prefer assert-ing to throwing an exception?

The latter spanks the user. The former spanks the programmer.

--
Phlip
http://industrialxp.org/community/bi...UserInterfaces

[E. Robert Tisdale]

BigMan wrote:

When should one prefer assert-ing to throwing an exception?

The assert macro is used to help programmers detect bugs
and *not* exceptions.

An exception is an unpredictable but expected event
which cannot be prevented and must be handled.
Exceptions should be handled to the extent possible
at the point where they are first detected.
If the exception cannot be handled completely
in the function where it is first detected,
all of the information required to handle the exception
in the calling program should be encoded in an exception object
and that object should be passed back to the calling program
as a return value by "throwing an exception".

Programming errors (bugs) are *not* exceptions.
Bugs are unexpected events which, once detected,
are always predicable and preventable by fixing the bug.
You can't "handle" bugs except by fixing them.
Once you have found and fixed all of the bugs,
the assert macros are no longer necessary
and you should turn them off by defining the NDEBUG macro.

Allowing assertions to persist in distributed software
only means that you haven't finished testing and debugging.
This is sometimes acceptable in alpha and beta distributions
but very unprofessional otherwise.

[BigMan]

My experience shows that if the caller of a library function must take
further actions based on the return value (e.g. in a switch statement),
they should watch out for unexpected return values (usually one puts a
default clause to catch such cases). So, should I assert( false); in
the default clause or should I throw an exception there?
And what about the case where the same developer implements the caller
and the callee in the same source file?

[Phlip]

BigMan wrote:

My experience shows that if the caller of a library function must take
further actions based on the return value (e.g. in a switch statement),
they should watch out for unexpected return values (usually one puts a
default clause to catch such cases). So, should I assert( false); in
the default clause or should I throw an exception there?
Whose fault is the error? You describe a programmer not implementing all
possibilities in a switch. That's an assertion.

However, if a long list of return values might be the user's fault, throw an
exception. For example, if you disconnect your 'net connection, the sockets
library could return any number of time-outs, dropped signals, etc.
Translate them into a string and stick them into the user's face.

Also, write all your code exception-safe and exception-neutral. You should
generally roll state back to the point of the last program input.
And what about the case where the same developer implements the caller
and the callee in the same source file?

Not relevant - the biggest distinction is whether the fault is the user's or
the programmer's. For example, users should not disconnect their 'net
connections while browsing. (Your ISP is also a user;)

--
Phlip
http://industrialxp.org/community/bi...UserInterfaces

[lilburne]

BigMan wrote:

My experience shows that if the caller of a library function must take
further actions based on the return value (e.g. in a switch statement),
they should watch out for unexpected return values (usually one puts a
default clause to catch such cases). So, should I assert( false); in
the default clause or should I throw an exception there?
And what about the case where the same developer implements the caller
and the callee in the same source file?

Here we have a simple rule on who gets to fix a bug.

"The person with responsibilty for the code that supplied the
input that asserted gets to fix the code."

after 15 years of this policy it is typical to find in our methods more
asserions than live code.

In your example of a switch most of our default statements will
ASSERT_MISSING_ CASE.

[Phlip]

lilburne wrote:

Here we have a simple rule on who gets to fix a bug.

"The person with responsibilty for the code that supplied the
input that asserted gets to fix the code."

after 15 years of this policy it is typical to find in our methods more
asserions than live code.

That is such a good rule that I should not go extreme on you.

However, some people claim a team should pair program, rotate pairs
frequently, own tasks not code, and work on any code in the system to finish
a task. Shared code ownership leads to elegant code that looks like it was
written by a single, very intellegent, individual. However, the team might
honestly not know who wrote what code.

They also claim this policy leads to a very low defect rate, and a very high
test/code ratio.

--
Phlip
http://industrialxp.org/community/bi...UserInterfaces