Assert

August 19, 2005 6:28 PM

I need something to use instead of assert() in C/C++, but with similar properties

So I have the source code for this library that I use. It is liberally sprinkled with assert()s all over the place. These are used to halt the execution when something goes wrong. The thing is, since it's a library, something going wrong in one thread halts the whole program, and I'd prefer that it dies a bit more gracefully. I guess it was probably designed to be run with only one thread.

Anyway, I wrote a wrapper for this library, that brings it into my programming language of choice for this project, Tcl/Tk. What I'd like to do is use something *like* assert, which will halt execution of the command, no matter how "deep" it is, but still be handleable/trappable by the wrapping function.

There are at least 100 asserts in this program. It simply is not an option for me to find each one, remove the assert and change it with a return that indicates to the caller that an error occurred (especially since the execution chain for this library runs QUITE deep).

I'm on the verge of making it into a standalone executable, and execing it. Seriously. At least that way, one instance failing will not bring the whole program to a crash.

Any ideas?

posted by RustyBrooks to Computers & Internet (7 answers total)

Best answer: Exceptions do exactly this. Exactly, exactly this.
posted by devilsbrigade at 6:57 PM on August 19, 2005

Best answer: Yes, exceptions were created for this purpose. In addition to helping the modules exit "gracefully", they provide the abilty to do clean up (try... catch... finally...) and pass debug information back up the exception chain.
posted by SPrintF at 7:25 PM on August 19, 2005

Does Tcl/Tk have an exception-handling capability? He's still going to have to go in and replace all the asserts with try blocks that throw meaningful exceptions.

Is there no way to figure out what the asserts are trying to deal with and test for the condition in your wrapper before calling the library functions?
posted by mzurer at 8:04 PM on August 19, 2005

Response by poster: The asserts are actually all done via macros so I just have to change that one occurrence. The wrapper is written in C++ so I can put the exception logic in there.

The problem basically is that the data that goes into this library is sort of "dirty" and it's quite difficult to tell what it's going to object to, or even trace back why it's failing in the first place. It was not written to handle exceptional circumstances well. That's ok -- when it fails, it fails, I can fall back to something else, but it's no good if it takes the app with me.

I'll try out the exception stuff tonight. I didn't actually know that C++ had exception logic quite like that.
posted by RustyBrooks at 9:06 PM on August 19, 2005

There's a way to disable assertions altogether; I can't remember it but google indicates that defining NDEBUG before including assert.h will do the trick. You could also simply define your own assert macro (since I believe it is just a macro in assert.h) instead of including assert.h. This could e.g. throw an exception instead of printing out some stuff and halting. Assuming the wrapper is c++, it could just catch the exception and handle it gracefully.
posted by advil at 9:14 PM on August 19, 2005

Response by poster: disabling assertions doesn't really work in this case (I tried that first) -- the errors it encounters eventually will cause core dumps, divide by zeros, etc.

I basically am doing it by redefining the assert macro, as mentioned above.
posted by RustyBrooks at 10:23 PM on August 19, 2005

Response by poster: OK, now I'm back on track, thanks guys. I raided the definition of the assert macro in VC++ to see how they "did it" -- that is, how they turned the expression into a proper macro, made a string out if it plus the line numbers and what not, and it works great. Now instead of crashing and opening a window with the debug info, it simply throws a Tcl error (which is fully catchable if desired) with the same information. No changes to the code required, which is great.

Also, this will make debugging the asserts a LOT easier since it won't close the application when an error occurs, so I can scroll around, open a debug window, etc.
posted by RustyBrooks at 12:10 AM on August 20, 2005