Unix signal causing GUI to exit

[wysota]

But sometime the error may come from user inputs, and it is hard to catch all the errors that users may enter from the GUI.

Everything that comes from user input may be validated.

For instance, I want to allocate an array

float* array = new float[ size ]

where the "size" comes from user input. If user input "-1", it may crash.

It's easy to check that. Especially that you should get an exception you can catch.

But let's say you forget to check,

Well then don't forget it

Simply crash the application is not a nice way in handling such error. It is much nicer to allow user a chance to save the data so he/she doesn't lose what has been done so far.

Of course this is my personal opinion but applications crashes (let's call intercepting a SIGSEGV a crash as well) are caused by developers, not end-users.

I have seen such signal intercepting before. But I don't know how to implement it. The GUI never disappears unless you click "Exit" or "kill -9". It gives error message to allow users choose other approaches.

It all depends where the crash occurs. Qt is a high level framework. It's not safe to bail out of any method in any place possible. I'm sure if you corrupted the instruction pointer, the solution you mention wouldn't have worked. And it's easy to corrupt the instruction pointer by overwriting the stack frame through buffer overruns for example.

Last years, we evaluated several vendor applications, there were several applications crashed (GUI disappearing) in the middle of evaluation tests. The testers immediately throw it to junk list...It really makes a big difference...

I'd do the same regardless if they showed me a crash handler dialog or not. If an application crashes, it is badly written. If it crashes and shows a crash handler dialog it is also badly written and the only difference is that developers instead of fixing the bugs in question try to hide them or reduce damage made by them using the mentioned handlers. But the bugs are still there.

[faldzip]

as far as i know, the best way to catch the unwanted behavior is to run application under debugger and check for all bugs :] Testing is more important, more expensive and more time consuming than writing code. The better the application is designed, the better is written, the less bugs are in the first compilable version. So my advice is to not catch SIGSEGV but to fix the bug which causes the SIGSEGV.

P.S. Fixing bugs in testing phase can be even 100 more expensive and time consuming than fixing those bugs in design phase :]

[lni]

I completely agree what you two are saying. I also understand that any crash is due to bad codes, and it is the developers that need to be blamed.

Unfortunately, no software is bug free. So what I am hoping is that in the event there is an uncaught bug, the GUI application should give a best effort to provide a nicer way of ending the application...

Having said that, I hope someone can find a solution to the problem...

[wysota]

You can spawn a separate application as a crash handler. But I advise against continuing the original application.