On Jun 26, 2008, at 8:33 PM, bulia byak wrote:
On Thu, Jun 26, 2008 at 10:49 PM, MenTaLguY <mental@...3...> wrote:
As has been demonstrated in this and many other cases, using hard assertions during development is the best way to guarantee that bugs are found and fixed quickly.
These particular crashes are found and fixed, yes. But how can you be sure that there are no other assert-crashes that are missed by our sketchy developer-testing, get released, and make Inkscape feel crashy and flakey to the users - who therefore may feel disinclined to even report them?
This seems to be where we get into the subtle choices about assertions, warnings, exceptions, etc.
Generally an assertion should be a "this should never, ever, ever happen" thing in the code. For development and testing builds assertions can be "turned on", and then for release they can be "turned off"
Warnings should be for "I don't *think* this will happen, but if it does I really want to know about it. just in case"
Exceptions should be for "normally this bit of code will work, but when an unusual case hits we'll want to stop and recover"
and then return value error codes should probably be for "this call will not succeed in the normal course of things, so I need to check whether or not it did"
For Inkscape, I'm not familiar with the state of assertions and if they should be assert(), ASSERT(), g_assert(), etc. It's likely that we probably want to avoid bare assert() or g_assert() calls, and perhaps use some macro. Runaway memory, failure to malloc, etc. might fall into this case. (Most projects in C or C++ I've been on that have used asserts have wrapped them in turnon/turnoff macros)
If we have some code that gracefully handles some error condition and recovers from it, then that sounds like the time for a g_warning() call to be added at that point. Those allow operation to continue, but then developers can run with --g-fatal-warnings and get an exception thrown at the end of warning display.
For something low-level, throwing an exception might be the best there. So for our current issue the lib itself should optionally do a g_warning() (depending on precise code needs, etc) and then throw an exception. Up higher a calling routine (that happens to know more of the big picture, and more of what would be an appropriate recovery action) can catch any exception, log it, and then recover.