Quote Originally Posted by jacek View Post
So instead, you prefer to spend time on covering up the failure and trying to fix the errors it has caused using an unreliable mechanism, right? I prefer the fail-fast strategy.
If I have to perform some time intensive experiments and I'm short on time, so I know that I can barely make it with a non-crashing app, then I prefer it to crash now and then if I can continue the experiment without losing the already gathered data instead of debugging the application potentially for hours (remember the bug in the proxy model that caused you so much trouble?)

Too bad that you have changed your mind. Again.
I don't know what makes you think I changed my mind. I just remembered a real and useful example of trapping SIGSEGV where you can safely continue execution. If the app is broken, it's not safe to continue, but not every SIGSEGV means the app is broken.

First you give an example, then you write about my example:
I give you an example that there exists a possibility of using the approach and you counter with an argument that it might not always be possible to use it. I never said it was the UniversalWayOfDoingThings(TM).

I see the pot is calling the kettle black.
I'm afraid I don't know that phrase...


Quote Originally Posted by ad5xj
However I still get a program stop due to some event in the shared library (unexplained by debug messages) on the addDatabase call.
That's perfectly normal when using a debugger. Just continue execution.