Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > Understanding Assert and Exceptions

Reply
Thread Tools

Understanding Assert and Exceptions

 
 
mailforpr@googlemail.com
Guest
Posts: n/a
 
      10-14-2006
Sometimes, I can't think of any good reason why I should have the
program's logic thrown an exception. Except for catching the exception
and printing "Uh, oh" to the screen. I also think that in most cases
there's simply no way to handle an exception properly, because what can
one do about an integer overflow? Reassign values? Restart the program?
The problem will still be existing. I think that an integer overflow is
not an exception, but sluttish programming.

Now I think printing a message "There's a bug - I'm so sorry" is much
better than some bizarre error message provided by the operating
system. Kind of better than assert, which disappears when I compile the
release version and causes the bizarre error message if the bug's still
there.

My conclusion: throwing an exception is still better than assert, for
you can always print a user friendly message to the screen. You could
even provide a dialog or something and ask the user to write down the
steps that caused the bug in a text field.

I saw some guy named "lilburne" say "Use always assert, unless you have
no other choice, but even then consider the exception to be a design
flaw to be eliminated."

Somehow, I agree. After all, if you check for an error condition, then
in some sense you expect it to happen and it is no exception
whatsoever.

Now, if you happen to have any exceptional situations and you deside to
throw an exception, this is more an excuse for poor programming, I
think. Again, what can one do about an integer overflow? Or a wrong
static_cast?

Knowing that something went wrong seems to be the only good point about
exceptions to me anyway. But then again, I am all for assert, as they
don't throw an excuse to the end user. But this has to be done, anyhow.


What do you think?

 
Reply With Quote
 
 
 
 
mailforpr@googlemail.com
Guest
Posts: n/a
 
      10-14-2006
Correction: ... as they don't throw an excuse AT the end user.

 
Reply With Quote
 
 
 
 
Frederick Gotham
Guest
Posts: n/a
 
      10-14-2006
posted:

> Sometimes, I can't think of any good reason why I should have the
> program's logic thrown an exception.



There's isn't really a rule of thumb -- it's intuition more than anything.


> My conclusion: throwing an exception is still better than assert, for
> you can always print a user friendly message to the screen. You could
> even provide a dialog or something and ask the user to write down the
> steps that caused the bug in a text field.



Unless, of course, you hijack "assert" and make it more user-friendly.


> I saw some guy named "lilburne" say "Use always assert, unless you have
> no other choice, but even then consider the exception to be a design
> flaw to be eliminated."
>
> Somehow, I agree. After all, if you check for an error condition, then
> in some sense you expect it to happen and it is no exception
> whatsoever.



People who make blanket rules of thumb like that tend to be improficient.


> What do you think?



I use "assert" to indicate that something WRONG... W-R-O-N-G has happened,
such as a letter being '7'.

I throw an exceptio when something exceptional has happened, such as when a
random number is exactly 256.

--

Frederick Gotham
 
Reply With Quote
 
Thomas Tutone
Guest
Posts: n/a
 
      10-14-2006

Frederick Gotham wrote:


> I use "assert" to indicate that something WRONG... W-R-O-N-G has happened,
> such as a letter being '7'.
>
> I throw an exceptio when something exceptional has happened, such as when a
> random number is exactly 256.


Why would that warrant an exception?

Fred, show us some real code where you would throw an exception in that
instance.

I use exceptions quite a bit (e.g., in a compiler when the source code
has a syntax error), but I don't know anyone who would use an exception
the way you suggest, except in jest.

Best regards,

Tom

 
Reply With Quote
 
Kai-Uwe Bux
Guest
Posts: n/a
 
      10-14-2006
http://www.velocityreviews.com/forums/(E-Mail Removed) wrote:

> Sometimes, I can't think of any good reason why I should have the
> program's logic thrown an exception. Except for catching the exception
> and printing "Uh, oh" to the screen. I also think that in most cases
> there's simply no way to handle an exception properly, because what can
> one do about an integer overflow? Reassign values? Restart the program?
> The problem will still be existing. I think that an integer overflow is
> not an exception, but sluttish programming.
>
> Now I think printing a message "There's a bug - I'm so sorry" is much
> better than some bizarre error message provided by the operating
> system. Kind of better than assert, which disappears when I compile the
> release version and causes the bizarre error message if the bug's still
> there.
>
> My conclusion: throwing an exception is still better than assert, for
> you can always print a user friendly message to the screen. You could
> even provide a dialog or something and ask the user to write down the
> steps that caused the bug in a text field.
>
> I saw some guy named "lilburne" say "Use always assert, unless you have
> no other choice, but even then consider the exception to be a design
> flaw to be eliminated."
>
> Somehow, I agree. After all, if you check for an error condition, then
> in some sense you expect it to happen and it is no exception
> whatsoever.
>
> Now, if you happen to have any exceptional situations and you deside to
> throw an exception, this is more an excuse for poor programming, I
> think. Again, what can one do about an integer overflow? Or a wrong
> static_cast?


Those are not examples where exceptions should be used. You use exceptions
to indicate failures that are not bugs. E.g.:

class TCP_Connection {

TCP_Connection ( some args )
: some initializations
{
try to establish the connection.
if you fail, throw an exception indicating the failure.
}

...
};

It is pretty clear that an assert would be wrong: even if your code is 100%
correct, the computers network might just be down. Also, the program can do
something in this case: catch the exception and tell the user to bring up
the network and to try again then.

The point of throwing the exception is to separate concerns: the
TCP_Conncection class could provide handling in place. However, that is
less flexible. It can become unacceptably rigid, if TCP_Connection is part
of a library. Then you want the client to be able to decide how errors
should be handled. Thus, you just throw an exception and let the client
provide the handler. That is what exceptions are designed for: postponing
the handling of resource failures.


> Knowing that something went wrong seems to be the only good point about
> exceptions to me anyway. But then again, I am all for assert, as they
> don't throw an excuse to the end user. But this has to be done, anyhow.


Huh?


Best

Kai-Uwe Bux
 
Reply With Quote
 
=?ISO-8859-15?Q?Juli=E1n?= Albo
Guest
Posts: n/a
 
      10-14-2006
(E-Mail Removed) wrote:

> I saw some guy named "lilburne" say "Use always assert, unless you have
> no other choice, but even then consider the exception to be a design
> flaw to be eliminated."
> Somehow, I agree. After all, if you check for an error condition, then
> in some sense you expect it to happen and it is no exception
> whatsoever.


Maybe we need a new concept, in addition to exceptions we can introduce
the "impossibilities". Instead of failing an assertion, we throw an
impossibility, like throwing an exception but without any way to catch it
X-)

More seriously: an exception is not (for me and meny others) something I'm
sure will never happen. It's something that, for infrequent of for the way
yo handle it, is better to keep separate from the normal flow.

For example, reaching eof when reading a text file is hardly considered
exceptional, but reaching it in the middle of a field of fixed length in a
binary file is a good candidate for exception.

Maybe this can also be considered a design flaw, we must design systems when
files never are corrupted, disks never fails, users don't make mistakes...
Maybe eliminate users can be a first step in that direction?

--
Salu2
 
Reply With Quote
 
Jim Langston
Guest
Posts: n/a
 
      10-15-2006
<(E-Mail Removed)> wrote in message
news:(E-Mail Removed) oups.com...
> Sometimes, I can't think of any good reason why I should have the
> program's logic thrown an exception. Except for catching the exception
> and printing "Uh, oh" to the screen. I also think that in most cases
> there's simply no way to handle an exception properly, because what can
> one do about an integer overflow? Reassign values? Restart the program?
> The problem will still be existing. I think that an integer overflow is
> not an exception, but sluttish programming.
>
> Now I think printing a message "There's a bug - I'm so sorry" is much
> better than some bizarre error message provided by the operating
> system. Kind of better than assert, which disappears when I compile the
> release version and causes the bizarre error message if the bug's still
> there.
>
> My conclusion: throwing an exception is still better than assert, for
> you can always print a user friendly message to the screen. You could
> even provide a dialog or something and ask the user to write down the
> steps that caused the bug in a text field.
>
> I saw some guy named "lilburne" say "Use always assert, unless you have
> no other choice, but even then consider the exception to be a design
> flaw to be eliminated."
>
> Somehow, I agree. After all, if you check for an error condition, then
> in some sense you expect it to happen and it is no exception
> whatsoever.
>
> Now, if you happen to have any exceptional situations and you deside to
> throw an exception, this is more an excuse for poor programming, I
> think. Again, what can one do about an integer overflow? Or a wrong
> static_cast?
>
> Knowing that something went wrong seems to be the only good point about
> exceptions to me anyway. But then again, I am all for assert, as they
> don't throw an excuse to the end user. But this has to be done, anyhow.
>
>
> What do you think?


I normally very seldom throw, but I tend to use assert a bit. But there are
good reasons for using throw and catch.

One reason I am doing it is because I have a function that returns a
referernce to a map, although the key may not exist in the map. I got into
a quandry as to what do I return, how do I tell the calling method that the
key was not found, and the best solution I came up with was to throw if it
was not found, and I found out it worked rather well.

CPlayer& FindPlayer( const SOCKET Socket )
{
// Get a reference in the map for this player
map_player::iterator it = World.ConnectedPlayers.find( Socket );
if ( it != World.ConnectedPlayers.end() )
return (*it).second;
else
throw 0;
}

// First lets see if this player is already connected.
try
{
FindPlayer( wsp.Name );
// We didn't throw, so the player name is already logged in
World.MessageBuffer.push_back( LogMessage( "Player " +
jml::StrmConvert( wsp.Name ) + " Tried to log in twice. IP " + IP ) );
return ACCEPT_CLIENT | ( MSG_ALREADY_LOGGED_IN << 8 );
}
catch ( int )
{
}

// later

try
{
CPlayer& ThisPlayer = FindPlayer( Socket );
PlayerLeft( ThisPlayer );
}
catch ( int )
{
World.MessageBuffer.push_back( "Unlogged in socket " +
jml::StrmConvert( Socket ) + " disconnected." );
}

Basically, I will only throw if I can catch it and do something about it,
and there is no better way to handle handle it (return a value from the
function, etc...)

Assert I use only when I want to make sure code isn't running, or that some
value is true when I'm designing. Here's one case (that is actually not
needed)

class CMap
{
private:

// No copy or assignment yet so disable by making private.
CMap ( CMap const& /*CopyThis*/ ) { assert ( false ); }; // Copy
constructor.
CMap& operator=( CMap const& /*CopyThis*/ ) { assert ( false ); }; //
Assignment.
// ...
}

I have made the copy and assignment constructors private beause this class
can not be copied (pointers, etc..) so I just threw the assert in there to
make sure somehow it was never being called (but since it's private, it
shouldn't anyway).

exceptions and assert are tools, and as such should be used when they are
appropriate. It is said that when all you have is a hammer, then everything
starts to look like a nail, but in this case we have many more tools in our
toolboxes.


 
Reply With Quote
 
Roland Pibinger
Guest
Posts: n/a
 
      10-15-2006
On Sat, 14 Oct 2006 19:17:44 -0400, Kai-Uwe Bux wrote:
>The point of throwing the exception is to separate concerns: the
>TCP_Conncection class could provide handling in place. However, that is
>less flexible. It can become unacceptably rigid, if TCP_Connection is part
>of a library. Then you want the client to be able to decide how errors
>should be handled. Thus, you just throw an exception and let the client
>provide the handler. That is what exceptions are designed for: postponing
>the handling of resource failures.
>
>> Knowing that something went wrong seems to be the only good point about
>> exceptions to me anyway. But then again, I am all for assert, as they
>> don't throw an excuse to the end user. But this has to be done, anyhow.

>
>Huh?


assert is a debug aid, ie. the only purpose of assert is to find bugs
in your program. assert is a macro that is not present in the release
version of the program.
OTOH, exceptions indicate expected runtime failures and errors (but
not bugs). They need to be handled (caught) in the program somewhere.
In sum, asserts and exceptions serve different purposes and have
nothing to do with each other.

Best wishes,
Roland Pibinger
 
Reply With Quote
 
benben
Guest
Posts: n/a
 
      10-15-2006
Let's say you are writing a banking program. You are using libraries to
do certain tasks so you don't have to reinvent the wheel. And in one of
the libraries there is one very nifty function:

void perform_transaction();

Now as a user of the library what do you expect when perform_transaction
encounters an exceptional condition such as a runtime error?

What happens if all perform_transaction does is to prints out "Uh, oh,
blah blah blah". Not a good idea because:

1. There is no screen
2. Even if there is a screen it doesn't know what language should be used
3. It fails to stop you, the caller, from doing the next step. If your
next step is to ask the user to pay for the transaction, you will get a
customer complain.

Hope that convinces you that perform_transaction() really shouldn't
handle the exception on its own. What it should do, is to stop the
current transaction and notify you, the caller, what just happened, so
you can handle the problem better because you know if there is a screen,
the language of the customer and how to drop the interaction etc.

Regards,
Ben
 
Reply With Quote
 
David Harmon
Guest
Posts: n/a
 
      10-15-2006
On 14 Oct 2006 16:12:44 -0700 in comp.lang.c++, "Thomas Tutone"
<(E-Mail Removed)> wrote,
>
>Frederick Gotham wrote:
>
>
>> I use "assert" to indicate that something WRONG... W-R-O-N-G has happened,
>> such as a letter being '7'.
>>
>> I throw an exceptio when something exceptional has happened, such as when a
>> random number is exactly 256.

>
>Why would that warrant an exception?


It's supposed to be between 0 and 1.

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Understanding assert code Sami C Programming 14 11-09-2010 03:40 PM
To assert or not to assert... ImpalerCore C Programming 79 05-17-2010 12:47 PM
assert 0, "foo" vs. assert(0, "foo") Thomas Guettler Python 3 02-23-2005 07:53 PM
assert(x) and '#define ASSERT(x) assert(x)' Alex Vinokur C Programming 5 11-25-2004 08:48 PM
RE: remove assert statement (Was: Re: PEP new assert idiom) Robert Brewer Python 1 11-07-2004 06:53 PM



Advertisments