How to crash gracefully

[rbp]

hi,

when a program like Firefox or Sketchup crashes we get a nice Dialog saying what has happened.
How would I implement something like that for my own Qt app?

I naively tried this:

try {
        app.exec();
}
catch(...) {
        // launch crash dialog
}

try {
        app.exec();
}
catch(...) {
        // launch crash dialog
}

To copy to clipboard, switch view to plain text mode 

which does not work because Qt does not use exceptions.

Is there a platform independent solution to make my app crash gracefully? Or do I need to look into signals on Linux, etc.

Richard

[mcosta]

I usually use a slot fatalError(const QString&) in program's Main Window and connect this with children's signal fatalError(const QString&).

The code of MainWindow::fatalError can be:

void MainWindow::fatalError(const QString& _details)
{
    QMessageBox mbox(
        QMessageBox::Critical,
        tr("Fatal Error"),
        tr("%1 has encountered an error and cannot continue to work.\n"
           "Please press OK button to quit.").arg(qApp->applicationName()),
        QMessageBox::Ok,
        this);
 
    mbox.setDetailedText(_details);
 
    mbox.exec();
    qApp->quit();
}

void MainWindow::fatalError(const QString& _details)
{
    QMessageBox mbox(
        QMessageBox::Critical,
        tr("Fatal Error"),
        tr("%1 has encountered an error and cannot continue to work.\n"
           "Please press OK button to quit.").arg(qApp->applicationName()),
        QMessageBox::Ok,
        this);

    mbox.setDetailedText(_details);

    mbox.exec();
    qApp->quit();
}

To copy to clipboard, switch view to plain text mode 

[rbp]

how do the child widgets know when to emit fatalError()?

[mcosta]

You can catch failure conditions and emit fatalError

[rbp]

that seems to be back to my original problem, except with the child widgets instead of the main window. I have found I can't catch errors because Qt doesn't use exceptions.

How do you catch all errors for a widget?

[mcosta]

Sorry, but I don't understand the question!

Qt don't use exceptions for signaling errors but each method returns a value (typically a boolean) that indicates the result of the executed operations.

You can test this value and emit the fatalError signal.

If you give some examples, I can help you.

[rbp]

ah OK, yeah I already handle those kind of anticipated errors.

What I'm aiming at is handling unexpected errors - even a great app like Firefox crashes unexpectantly sometimes. See here.
If/when my app crashes I want them to send debugging information to a central server. But so far I haven't figured out how to 'catch' the crash.

[lni]

Don't think you can find any help from here on this issue, see this:
http://www.qtcentre.org/forum/f-qt-p...xit-20172.html

[wysota]

If/when my app crashes I want them to send debugging information to a central server. But so far I haven't figured out how to 'catch' the crash.

If your application crashes, you have to be prepared for the crash - you have to expect it to crash in a particular place. Crash is either an unhandled exception that you can catch (Qt doesn't throw exceptions but it doesn't prevent exceptions to be thrown from other classes/functions) or a situation when you violate an OS policy and your application gets terminated. If the crash happens in your code, you can use exceptions and do some cleanup. If the crash happens unexpectedly then using GUI (or network) is probably unsafe anyway as I said in the thread quoted by Ini.

If you force firefox to sigsegv, it won't close gracefully, it will just be terminated. The feedback thingy is probably an external application that gets executed when a crash occurs and that you can do with your application as well upon a sigsegv. But it won't give you much meaningful information (except a backtrace).

[lni]

If your application crashes, you have to be prepared for the crash - you have to expect it to crash in a particular place. Crash is either an unhandled exception that you can catch (Qt doesn't throw exceptions but it doesn't prevent exceptions to be thrown from other classes/functions) or a situation when you violate an OS policy and your application gets terminated. If the crash happens in your code, you can use exceptions and do some cleanup. If the crash happens unexpectedly then using GUI (or network) is probably unsafe anyway as I said in the thread quoted by Ini.

If you force firefox to sigsegv, it won't close gracefully, it will just be terminated. The feedback thingy is probably an external application that gets executed when a crash occurs and that you can do with your application as well upon a sigsegv. But it won't give you much meaningful information (except a backtrace).

see this: http://www.slb.com/media/services/so...dk/CSL_Exc.pdf

[wysota]

see this: http://www.slb.com/media/services/so...dk/CSL_Exc.pdf

I'm not sure what point are you trying to give by referring that document. C++ has its own exception system which seems a bit more advanced than that of CSL (still crappy though). And by the way, SIGSEGV and SIGBUS are not exceptions (they are much more serious than exceptions, they are "generated" by the operating system), let's not mix the concepts (it's as if we said C was an object oriented language because it supported structures).

[lni]

I'm not sure what point are you trying to give by referring that document. C++ has its own exception system which seems a bit more advanced than that of CSL (still crappy though). And by the way, SIGSEGV and SIGBUS are not exceptions (they are much more serious than exceptions, they are "generated" by the operating system), let's not mix the concepts (it's as if we said C was an object oriented language because it supported structures).

You may be right that CSL is crappy. But that codes work. That is probably one of the reasons that Schlumberger software has had much better sale than most other competitors.

The concept is easy to understand, when an exception or signal is raised, the signal handler catch and throw an exception, and event handler process the exception and never let the exception handler return out of the function. If the exception handler return from the function, it will go back to where it crashes, which will trigger exception handler again, causing a dead loop.

So the idea is to throw out of the crash point, and let the program return back to the normal event loop, the problem is then solved... Schlumberger can do it, I think Qt can do it too...

Let's not talk about SEGV, let's do "man abort", and see what is said: "The abort() function shall cause abnormal process termination to occur, unless the signal SIGABRT is being caught and the signal handler does not return". I just don't know how to do it in Qt...Perhaps you know it...

There is no example on Qt for this: http://doc.trolltech.com/main-snapsh...x-signals.html