Link to home
Start Free TrialLog in
Avatar of gavinpat
gavinpat

asked on

debugging versions

I have a program in which the previous programmer has used a flag (called AL_DEBUG) to specify whether a program is a debug or release version.  When AL_DEBUG is set conditional compile statements include extra run time error handling code.  Note this is not done by exception handling.  Most of the code is for simply checking pointers to make sure they contain an object before continuing.  I assume that this is easily done by exception handling but would it lead to unnecessary code bloat?  I am quite happy with the fact that my AL_DEBUG flag is in no way compiler dependent and so my code is relatively portable at the moment. Also - does anyone know of a good book that covers exception handling in detail as I don't have one at the moment.
ASKER CERTIFIED SOLUTION
Avatar of nietod
nietod

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of nietod
nietod

Exceptions are a very powerful way to deal with errors, but they are best used for handling errors that are "predictable"  but that I mean that there are some errors that you expect to have happen from time to time and have a way to recover from them.  Things like trying to open a file that was there a minute ago and now is not.  Or trying to allocate memory and finding there is not enough free memory.  In contrast often there are errors that you sort of never expect to have occur--after the code is debugged.  Like writing 100 bytes to a file and finding that the file length is 99 bytes.

Exceptions are good for the first kind of error.  This is because the error can occur in a final release version and because you can handle the error (somewhat) gracefully).  However, the second type of errors are best handled by asertions (ASSERT()) or conditional code that is removed in the final product.  They could be handled, by exceptions, but there is usually no point as, (1) they will almost never occur in the final product, (2) there is no way to handle them gracefully, (3) the overhead of exceptions is realitvely minimal, but is not worth it because if 1 and 2.

As to the code bloat (and run-time inneficiency) of exceptions, I recomend you look at "More Effective C++" by scott meyers.  It has a section on this in particular.  
Avatar of gavinpat

ASKER

I will have to have a look at the section you mention in More Effective C++. I am wondering how much you use the set_new_handler referred to in item 7 in Effective C++ as I am playing around with that and would like to use it. At the moment the code I am debugging has some strange characteristics e.g. loops that change the value of the loop counter! Thanks once again for the help.
I use set new handler.  My library creates a 32K block at startup as a safety net.  Then if new fails, I release part of this 32K block and display a message notifying the user that memory is low and they should try to close down unneeded components of the system.  Then I allow the new to retry, hopefully it will succeed because memory was freed from the initially grabbed 32K.

Are your loop counters being changed  by legitimately,  For example, in

for (int i = 5; i <= 10 ++i)
{
   i = 0
}

the loop counter will legitimately be changed to 0 and the loop will continue for ever.  Or do you have a weird bug that is causing the loop counter to be altered when it should not be?