Velocity Reviews - Computer Hardware Reviews

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

Reply
Thread Tools

Understanding Assert and Exceptions

 
 
Duane Hebert
Guest
Posts: n/a
 
      10-15-2006

"benben" <benhonghatgmaildotcom@nospam> wrote in message
news:45324e75$0$6625$(E-Mail Removed) ...
> 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.


So what's wrong with it becoming:
bool perform_transaction() and return false on
failure? Personally, I think throwing on a function
failure is bogus. I would reserve exceptions for exceptional
behavior and not for something that can be handled
easily by returning an error.


 
Reply With Quote
 
 
 
 
=?ISO-8859-15?Q?Juli=E1n?= Albo
Guest
Posts: n/a
 
      10-15-2006
Duane Hebert wrote:

> So what's wrong with it becoming:
> bool perform_transaction() and return false on
> failure?


Nothing "wrong". You can use any or other way depending on the intended use
of the function.

For example, if the function that calls perform_transaction does not want to
handle the error itself, but let it fall to the callee, it must do
something like:

if (! perform_transaction () )
{
// Maybe some cleaning here.
return false;
}

And with exception you only need:

perform_transaction ();

And the error handling does not get mixed with the normal flow of execution.

--
Salu2
 
Reply With Quote
 
 
 
 
Phlip
Guest
Posts: n/a
 
      10-15-2006
mailforpr wrote:

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


Write lots of unit tests that crunch your code in various ways.

The situations your tests can't get to, such as a NULL pointer where it
shouldn't be, deserve assert() statements.

The situations they _can_ get to, your users _might_ get to. So that code
should throw assertions, and the test cases should catch them and pass.

Put another way, asserts and exceptions without unit tests are just a
two-legged stool. Not very useful, and no point distinguishing which leg is
which!

--
Phlip
http://www.greencheese.us/ZeekLand <-- NOT a blog!!!


 
Reply With Quote
 
mailforpr@googlemail.com
Guest
Posts: n/a
 
      10-15-2006
benben wrote:
> 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.


Kai-Uwe Bux wrote:
> 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.



I see.

 
Reply With Quote
 
Duane Hebert
Guest
Posts: n/a
 
      10-15-2006

"Julián Albo" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Duane Hebert wrote:
>
>> So what's wrong with it becoming:
>> bool perform_transaction() and return false on
>> failure?

>
> Nothing "wrong". You can use any or other way depending on the intended
> use
> of the function.
>
> For example, if the function that calls perform_transaction does not want
> to
> handle the error itself, but let it fall to the callee, it must do
> something like:
>
> if (! perform_transaction () )
> {
> // Maybe some cleaning here.
> return false;
> }
>
> And with exception you only need:
>
> perform_transaction ();
>
> And the error handling does not get mixed with the normal flow of
> execution.


I don't get that. If you don't catch the exception
what is going to happen? At some point you
have to catch it and deal with the error anyway.


 
Reply With Quote
 
red floyd
Guest
Posts: n/a
 
      10-16-2006
Duane Hebert wrote:
> "Julián Albo" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>> Duane Hebert wrote:
>>
>> And with exception you only need:
>>
>> perform_transaction ();
>>
>> And the error handling does not get mixed with the normal flow of
>> execution.

>
> I don't get that. If you don't catch the exception
> what is going to happen? At some point you
> have to catch it and deal with the error anyway.
>
>


If an exception is uncaught, eventually terminate() is called, causing
your program to drop dead.
 
Reply With Quote
 
=?ISO-8859-15?Q?Juli=E1n?= Albo
Guest
Posts: n/a
 
      10-16-2006
Duane Hebert wrote:

>> And with exception you only need:
>>
>> perform_transaction ();
>>
>> And the error handling does not get mixed with the normal flow of
>> execution.

>
> I don't get that. If you don't catch the exception
> what is going to happen? At some point you
> have to catch it and deal with the error anyway.


The point is that at some point I, or some other programmer that use the
function, can catch the exception. Or just let the program terminate, if
it's a simple command line tool used for people that knows how is written.

--
Salu2
 
Reply With Quote
 
mlimber
Guest
Posts: n/a
 
      10-16-2006
Phlip wrote:
> mailforpr wrote:
>
> > Sometimes, I can't think of any good reason why I should have the
> > program's logic thrown an exception.

>
> Write lots of unit tests that crunch your code in various ways.
>
> The situations your tests can't get to, such as a NULL pointer where it
> shouldn't be, deserve assert() statements.
>
> The situations they _can_ get to, your users _might_ get to. So that code
> should throw assertions, and the test cases should catch them and pass.
>
> Put another way, asserts and exceptions without unit tests are just a
> two-legged stool. Not very useful, and no point distinguishing which leg is
> which!


In many cases, you're right, but in a good many other cases, there is
no practical way to write comprehensive unit tests in any reasonable
amount of time. On a complex embedded system, for instance, one must
accurately simulate the hardware and timing of the system to catch bugs
with unit tests, but doing so is often not feasible. Testing must be
done, of course, but by necessity, it must be to a lesser degree of
thoroughness than some other application domains enjoy.

Cheers! --M

 
Reply With Quote
 
Phlip
Guest
Posts: n/a
 
      10-16-2006
mlimber wrote:

> In many cases, you're right, but in a good many other cases, there is
> no practical way to write comprehensive unit tests in any reasonable
> amount of time.


If you write them as you write the tested code, you can typically save most
of the time you'd spend debugging.

I use them in this case as an example of exercising the code, to distinguish
accessible but unpreventable problems from programmer errors. There are
other ways.

> On a complex embedded system, for instance, one must
> accurately simulate the hardware and timing of the system to catch bugs
> with unit tests, but doing so is often not feasible. Testing must be
> done, of course, but by necessity, it must be to a lesser degree of
> thoroughness than some other application domains enjoy.


I thought embedded systems shunned exceptions, and I thought they also
leveraged alternative design techniques.

--
Phlip
http://www.greencheese.us/ZeekLand <-- NOT a blog!!!


 
Reply With Quote
 
mlimber
Guest
Posts: n/a
 
      10-16-2006
Phlip wrote:
> mlimber wrote:
>
> > In many cases, you're right, but in a good many other cases, there is
> > no practical way to write comprehensive unit tests in any reasonable
> > amount of time.

>
> If you write them as you write the tested code, you can typically save most
> of the time you'd spend debugging.
>
> I use them in this case as an example of exercising the code, to distinguish
> accessible but unpreventable problems from programmer errors. There are
> other ways.


Sure. But my point was that there are a good number of circumstances
where unit tests are simply not feasible (embedded systems is one,
legacy code with no existing unit tests is another) but where
exceptions and assertions can and should still be used.

> > On a complex embedded system, for instance, one must
> > accurately simulate the hardware and timing of the system to catch bugs
> > with unit tests, but doing so is often not feasible. Testing must be
> > done, of course, but by necessity, it must be to a lesser degree of
> > thoroughness than some other application domains enjoy.

>
> I thought embedded systems shunned exceptions, and I thought they also
> leveraged alternative design techniques.


Depends on the application of course, but Texas Instrument's (quite
conformant) C++ compiler supports exceptions for their DSPs.

Cheers! --M

 
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