473,320 Members | 1,870 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,320 software developers and data experts.

assert to exception : what is the scenario

Hi,
I have many assert() call in my code, now I am considering to replace
them with exception. The reason I want to do this change is that with
the program going bigger and bigger, it is hard to test all the corner
cases, and thus assert() does not work as good as before. The problem
is if there are something really bad which was not captured by
assert(), then in runtime, most likely the program will crash. This is
the worst user experience.

Exception at least is better in that it has "graceful" exit.

I did not use exception before as I was told gcc3.2.2 did not support
exception very well, now my company is using gcc 3.2.3 which I am told
is better to handle exception. (Is this true?)

My current plan is to do some sort of editor string replacement so
that assert() is to be exception.

One thing is, I use lofs of assert(), some of them are in pretty deep
function call chain stack, then that means I need to add "throw
exception" declaration to almost all the functions.

While I will only have one catch statement on the very top, so in
order for the top function to receive the exception, I need to have
"throw exception" all the way from the deepest function in the stack.

How do you think my plan, how about gcc3.2.3 exception support?

Any suggestion is highly appreciated.

Jul 23 '05 #1
10 4936

<li*****@hotmail.com> skrev i en meddelelse
news:11**********************@g14g2000cwa.googlegr oups.com...
Hi,
I have many assert() call in my code, now I am considering to replace
them with exception. The reason I want to do this change is that with
the program going bigger and bigger, it is hard to test all the corner
cases, and thus assert() does not work as good as before. The problem
is if there are something really bad which was not captured by
assert(), then in runtime, most likely the program will crash. This is
the worst user experience.

Exception at least is better in that it has "graceful" exit.

Assert is for debug, thus the user should not see that. But let us assume
that you do send your debug-code to beta-testers. In that case, the assert
is much better. It gives you a core dump that helps you find out what the
problem is.
I did not use exception before as I was told gcc3.2.2 did not support
exception very well, now my company is using gcc 3.2.3 which I am told
is better to handle exception. (Is this true?) Unfortunately, I cannot help you here.
My current plan is to do some sort of editor string replacement so
that assert() is to be exception. If you decide to hang on to your scheme, you should probably replace the
assert-macro with another macro. That macro could then test the condition
and do the job. Something like
#define assert_throw(_cond) do { if (!_cond) throw
my_assert_signal(#_cond); } while (false)
One thing is, I use lofs of assert(), some of them are in pretty deep
function call chain stack, then that means I need to add "throw
exception" declaration to almost all the functions. No. Only if those functions have a throw-specification already.

While I will only have one catch statement on the very top, so in
order for the top function to receive the exception, I need to have
"throw exception" all the way from the deepest function in the stack.

How do you think my plan, how about gcc3.2.3 exception support?
I believe assert is for debug-builds only - not something you would send to
a real user. Perhaps some of your asserts check your environment instead of
your logic?

Any suggestion is highly appreciated.


/Peter
Jul 23 '05 #2

linq...@hotmail.com wrote:
Hi,
I have many assert() call in my code, now I am considering to replace them with exception. The reason I want to do this change is that with
the program going bigger and bigger, it is hard to test all the corner cases, and thus assert() does not work as good as before. The problem
is if there are something really bad which was not captured by
assert(), then in runtime, most likely the program will crash. This is the worst user experience.

Exception at least is better in that it has "graceful" exit.


You should only use 'assert' in cases where the program *should* abort
if the assertion fails. In particular, use assert to enforce program
invariants (e.g,. a value that you stored into a container is in the
container when you 'find' it).

Use exceptions for *exceptional* errors for which there may or may not
be a recovery action (e.g., could not allocate memory from a pooled
allocator).

Use return codes for all other errors (e.g., could not connect to
server, result of translation from string to int failed, etc).

As for testing corner cases, an effective method is to break your
program into a hierarchy of (small) components with an explicitly
stated contract for each method, and test each component completely in
isolation from the bottom up. It helps a great deal to *state* the
contract for each method (what values are returned under various
circumstances, what is undefined behavior, what are the effects of
error conditions on arguments, etc) both for the purpose of writing the
implementation and for testing the method. If you can state the domain
and range of a function, it is fairly straightforward to test it.

/david

Jul 23 '05 #3

Peter Koch Larsen wrote:
<li*****@hotmail.com> skrev i en meddelelse
news:11**********************@g14g2000cwa.googlegr oups.com...
Hi,
I have many assert() call in my code, now I am considering to replace them with exception. The reason I want to do this change is that with the program going bigger and bigger, it is hard to test all the corner cases, and thus assert() does not work as good as before. The problem is if there are something really bad which was not captured by
assert(), then in runtime, most likely the program will crash. This is the worst user experience.

Exception at least is better in that it has "graceful" exit.

Assert is for debug, thus the user should not see that. But let us

assume that you do send your debug-code to beta-testers. In that case, the assert is much better. It gives you a core dump that helps you find out what the problem is.
I did not use exception before as I was told gcc3.2.2 did not support exception very well, now my company is using gcc 3.2.3 which I am told is better to handle exception. (Is this true?) Unfortunately, I cannot help you here.

My current plan is to do some sort of editor string replacement so
that assert() is to be exception.

If you decide to hang on to your scheme, you should probably replace

the assert-macro with another macro. That macro could then test the condition and do the job. Something like
#define assert_throw(_cond) do { if (!_cond) throw
my_assert_signal(#_cond); } while (false)

One thing is, I use lofs of assert(), some of them are in pretty deep function call chain stack, then that means I need to add "throw
exception" declaration to almost all the functions. No. Only if those functions have a throw-specification already.

While I will only have one catch statement on the very top, so in
order for the top function to receive the exception, I need to have
"throw exception" all the way from the deepest function in the stack.
How do you think my plan, how about gcc3.2.3 exception support?


I believe assert is for debug-builds only - not something you would

send to a real user. Perhaps some of your asserts check your environment instead of your logic?

Any suggestion is highly appreciated.


/Peter


Thanks for the reply.

Like you said assert() is for debug, for my case the assert() call will
be removed in optimized compile, it only stays in the debug version.

One thing I want to make sure, let's say the function call is like
this:
func1()
--> func2()
--> func3()
In func3() I throw an exception, and func3() declares "throw
exception". Then in order for func1() to receive the exception, func2()
must declares "throw expetion". Is this right?

More details like this,

int func1(){
...
try {
func2();
}
catch excpetion {
...
}
}

int func2() throw exception {
^^^^^^^^^^^^^^^^ -- I must have this declaration,
right?
func3();
}

int func3() throw exception {
...
throw exception;
}

Jul 23 '05 #4

<li*****@hotmail.com> wrote in message

Like you said assert() is for debug, for my case the assert() call will
be removed in optimized compile, it only stays in the debug version.

One thing I want to make sure, let's say the function call is like
this:
func1()
--> func2()
--> func3()
In func3() I throw an exception, and func3() declares "throw
exception". Then in order for func1() to receive the exception, func2()
must declares "throw expetion". Is this right?

More details like this,

int func1(){
...
try {
func2();
}
catch excpetion {
...
}
}

int func2() throw exception {
^^^^^^^^^^^^^^^^ -- I must have this declaration,
right?
func3();
}

int func3() throw exception {
...
throw exception;
}


Now you're talking about exception specifications. There is no requirement
that you provide exception specifications. Any function can throw an
exception, and any calling function can catch exceptions (either using the
catch-all "..." or the specific exception type). You do not have to declare
(nor have I ever used) exception specifications (unless of course that is
something your employer requires). Exception specifications do not actually
allow or prevent exceptions from being passed (or caught), but are rather
intended as a tool for programmers to use to know what exceptions *might* be
expected to be thrown out of a given function. But in practice, that may be
incredibly difficult to know for sure, and in the opinion of many (myself
included) they're just a waste of time.

-Howard

Jul 23 '05 #5
> While I will only have one catch statement on the very top, so in
order for the top function to receive the exception, I need to have
"throw exception" all the way from the deepest function in the stack.


Reading your description I do not think you will really benefit from
exceptions. The strength of exceptions is that they may be caught and
handled everywhere. If you only provide a top level catch clause (presumably
with some user interface telling that program is shutting down), you might
as well replace all asserts with a call to the function that does exactly
the same.

I do not see why you think that exceptions shut program more gracefully than
asserts. I believe it makes no difference whatsoever - the program just
crashes in both cases.

Moreover, it is often much easier to debug an assert-crashing program than
exception-crashing. The reason is the stack frame is still there in case of
assert, while in top-level exception handler it is already completely
unwound and useless. In other words you don't know where the exception is
coming from, unless you include that information in the exception itself.

cheers,
M.
Jul 23 '05 #6

Marcin Kalicinski wrote:
While I will only have one catch statement on the very top, so in
order for the top function to receive the exception, I need to have
"throw exception" all the way from the deepest function in the
stack.
Reading your description I do not think you will really benefit from
exceptions. The strength of exceptions is that they may be caught and handled everywhere. If you only provide a top level catch clause (presumably with some user interface telling that program is shutting down), you might as well replace all asserts with a call to the function that does exactly the same.

I do not see why you think that exceptions shut program more gracefully than asserts. I believe it makes no difference whatsoever - the program just crashes in both cases.

Moreover, it is often much easier to debug an assert-crashing program than exception-crashing. The reason is the stack frame is still there in case of assert, while in top-level exception handler it is already completely unwound and useless. In other words you don't know where the exception is coming from, unless you include that information in the exception itself.
cheers,
M.

While I do not quite agree with you. assert() is a macro, when you
build the code without DEBUG in the compiler option, it disappears from
the code. And if an error slips by, then it means crash.

Exception is better here because you can tell user some fatal error
happens, but user has the choise either close the application or call
some other utility. This does not cause the whole software crash.

I prefer exception over calling a function in that you still need come
out that function at some point, so you are still in trouble.

Thanks.

Jul 23 '05 #7
>>Moreover, it is often much easier to debug an assert-crashing program

than
exception-crashing. The reason is the stack frame is still there in
case of
assert, while in top-level exception handler it is already completely


unwound and useless. In other words you don't know where the


exception is
coming from, unless you include that information in the exception


itself.
cheers,
M.


While I do not quite agree with you. assert() is a macro, when you
build the code without DEBUG in the compiler option, it disappears from
the code. And if an error slips by, then it means crash.


The fact that it is a macro and it disapears from your code is a
feature. Assert is for testing correctness of your code. Assert
disapears when you are not debugging because this allows you to call
some heavy checking function inside it. For example:

* You could have a linked list (or some structure more complex). You may
want to test in many places if "n->next->prev == n" or not. You may want
to do this after each removal, or addition of elements. And you may want
to do for every element on the list for each addition or removal.

Also, you may enforce some policy: "Whenever you call a certain member
function, the object must necessarly be in a certain state. If it is
not, then it is a bug."

Exception is better here because you can tell user some fatal error
happens, but user has the choise either close the application or call
some other utility. This does not cause the whole software crash.
Assertions are there to prove that your code is right. What you want to
do needs no execption. Just a function for "cleaning up the mess".

I prefer exception over calling a function in that you still need come
out that function at some point, so you are still in trouble.


Assertion is not what you want because it is for development. But don't
assume that exception *is* what you want. Maybe you should do something
like:
assert( fact );
if ( ! fact ) clean_up_the_mess( __FILE__, __LINE__ );

But some "execptions" are not necessarly bugs (they could be a bad
input). And some bugs are very unlikely to happen if you passed the
development fase without them beeing "catched" by your "assertions". So,
some times you only need an "assert", some times you only need your
"clean_up_the_mess", and some times you need both.

By the way, what Marcin was saying was that it is much better to have a
clean_up_the_mess function then simply "if ( !fact ) throw MyException;"
because the exception messes up with the call stack.

Another thing. If you use assert for something that is not a real bug,
for example, a wrong input that would overflow some buffer, then you are
in trouble because the non-debug version will contain a buffer overflow
bug. Assert is for debugging only. Your program behaviour, supposing it
is free of bugs, should not change if they are ommited or not.

Andre Caldas.
Jul 23 '05 #8
Check out "Debugging Production Software" in the June, 2005 edition of
Dr. Dobb's.

</dib>

Jul 23 '05 #9

Andre Caldas wrote:
Moreover, it is often much easier to debug an assert-crashing
program
than
exception-crashing. The reason is the stack frame is still there in
case of
assert, while in top-level exception handler it is already
completely
unwound and useless. In other words you don't know where the


exception is
coming from, unless you include that information in the exception


itself.
cheers,
M.


While I do not quite agree with you. assert() is a macro, when you
build the code without DEBUG in the compiler option, it disappears from the code. And if an error slips by, then it means crash.


The fact that it is a macro and it disapears from your code is a
feature. Assert is for testing correctness of your code. Assert
disapears when you are not debugging because this allows you to call
some heavy checking function inside it. For example:

* You could have a linked list (or some structure more complex). You

may want to test in many places if "n->next->prev == n" or not. You may want to do this after each removal, or addition of elements. And you may want to do for every element on the list for each addition or removal.

Also, you may enforce some policy: "Whenever you call a certain member function, the object must necessarly be in a certain state. If it is
not, then it is a bug."

Exception is better here because you can tell user some fatal error
happens, but user has the choise either close the application or call some other utility. This does not cause the whole software crash.
Assertions are there to prove that your code is right. What you want

to do needs no execption. Just a function for "cleaning up the mess".

I prefer exception over calling a function in that you still need come out that function at some point, so you are still in trouble.
Assertion is not what you want because it is for development. But

don't assume that exception *is* what you want. Maybe you should do something like:
assert( fact );
if ( ! fact ) clean_up_the_mess( __FILE__, __LINE__ );

Let's say the function statck is like this,
main()
---> fun1()
---> fun2()
and in fun2() you have this clean_up_the_mess() called. The problem is
for the bug that assert() did not catch in debug version, that usually
is a critical one, that means after you clean up the messed
environment, the only option for you is to exit, not continue. But the
problem is you need to exit all the way from fun2(), to fun1(), and to
main() finally.

You need to have the code in each function to check the return the
value of the sub-function, fun1() checks fun2(), main() checks fun1(),
etc. Well this should be a good practice, in reality world, we do not.

That is the thing I love exception, it unwinds the function call stack
all the way up, until some point you believe it is necessary to do
clean up.

Maybe I do not get your idea in full, enjoying this thread.

Jul 23 '05 #10


li*****@hotmail.com wrote:
Hi,
I have many assert() call in my code, now I am considering to replace
them with exception. The reason I want to do this change is that with
the program going bigger and bigger, it is hard to test all the corner
cases, and thus assert() does not work as good as before.
<brag-mod>
The last time I checked our application has some 3,500,000 LOC
</brag-mod>

We use assertions everywhere and never throw. Our debug code runs 20-30
times slower than release primarily due to the assertion checks. The
level of checks that are perform could not be realistically done in
release code.

The problem
is if there are something really bad which was not captured by
assert(), then in runtime, most likely the program will crash. This is
the worst user experience.

Exception at least is better in that it has "graceful" exit.

Assertions test for programmer errors, exceptions test for user errors.
In the first case the program should crash, in the second case it shouldn't.
Jul 23 '05 #11

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

28
by: Fábio Mendes | last post by:
I'm sorry if it's an replicate. Either my e-mail program is messing with things or the python-list sent my msg to /dev/null. I couldn't find anything related in previous PEP's, so here it goes a...
3
by: Thomas Guettler | last post by:
Hi, Python 2.3.3 (#1, Feb 5 2005, 16:22:10) on linux2 >>> assert 0, "foo" Traceback (most recent call last): File "<stdin>", line 1, in ? AssertionError: foo >>> assert(0, "foo") >>>
11
by: BigMan | last post by:
When should one prefer assert-ing to throwing an exception?
21
by: Giuseppe | last post by:
is assert() for debug only or not? Is it possible that I have seen the use of assert() in the Borland c++ 32 compiler (so assert is not for debug only)?
2
by: cody | last post by:
System.Diagnostics.Debug.Assert(); Hello??? A language should encourage programmers to heavily use the assert-feature, since it improves safety, stability, readability and maintainability of...
28
by: lovecreatesbeauty | last post by:
Besides printing out for example " a.out: p113.c:8: main: Assertion `0' failed. Aborted " and a switch option NDEBUG, what other benefits does assert() provide in any scope of designing,...
29
by: mailforpr | last post by:
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...
8
by: werasm | last post by:
Hi all, Care to share your thoughts on this, or point me to some thoughts already shared. My thoughts are like this (from a systems point of view): When I have logic errors outside of my...
32
by: bingfeng | last post by:
hello, please see following two code snatches: 1. int foo (const char* some) { assert(some); if (!some) { return -1; //-1 indicates error }
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
1
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
0
by: CloudSolutions | last post by:
Introduction: For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
0
by: Defcon1945 | last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
0
by: Shællîpôpï 09 | last post by:
If u are using a keypad phone, how do u turn on JavaScript, to access features like WhatsApp, Facebook, Instagram....
0
by: Faith0G | last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.