How to manage unhandled exceptions?

[xalisonx]

Hey guys,
How to intercept unhandled exceptions?

In WPF I can trap unhandled exceptions at different levels:

AppDomain.UnhandledException From all threads in the AppDomain.
Dispatcher.UnhandledException From a single specific UI dispatcher thread.
Application.DispatcherUnhandledException From the main UI dispatcher thread in your WPF application.

How about Qt5?

Thanks!!

[A Former User]

Qt doesn't use exceptions. You have to do this on your own.

[xalisonx]

[quote author="Wieland" date="1424705837"]Qt doesn't use exceptions. [/quote]

Can you be more clear?

[A Former User]

Qt classes don't use C++ exceptions. They don't throw them, they don't catch them. And the framework does not help you in any way to handle them. This means, if you want to throw exceptions then you're free to do this, and if you want to catch them that's ok, too. But you have to do it with standard C++ stuff and no specific Qt stuff, because there is no specific Qt stuff for exceptions.

[xalisonx]

Oh wow! Then how to prevent my application closes after an unhandled exception?

[Chris Kawa]

As Wieland said - Qt doesn't throw exceptions. If you have an exception thrown somewhere it's your code doing it, not Qt.

The question is why would there be an unhandled exception in your app?
If something in your code throws, something in your code should expect it to throw and catch it.

If you just put a giant try/catch around your app to prevent it from crashing how can you make sure it does what it is supposed to?

[A Former User]

The bad news is, that you need a

@
try {
...
} catch (...) {
...
}
@

around everything you expect to throw. The good news is, that you'll almost never need this, because Qt classes themselves don't throw.

[Chris Kawa]

Whenever I see
@
} catch (...) {
@
I smell a bug-report coming soon and usually I'm right. It's a very good indicator of a certain way of thinking: "I don't know what this stuff does but it crashes my app so I'll just catch anything it throws at me, ignore it, and pretend nothing happened." otherwise known as "I'll sweep it under a rug and see if anybody notices. If not then I consider it fixed".

It's a kind of "philosophical dilemma":http://en.wikipedia.org/wiki/If_a_tree_falls_in_a_forest ;)

[A Former User]

.. and it's definitely a good starting point for a major flamewar :-D

[Chris Kawa]

Good point. I'm shutting up now :)

[xalisonx]

Thanks guys!
It is not all clear.

Let me give an example:

@QJsonObject *o = NULL;
qDebug()<<o->empty();@

Ok this code is bad, I know, but crash my application!!!
How to "catch" this kind of errors?

[Chris Kawa]

Null pointer dereference is a software bug. You should not catch it. You should let it crash during testing and fix the bug. Use assert().

If allowing a null value is part of your design (perfectly valid sometimes) then you should test the pointer before using it.

[xalisonx]

Okay, you're right. But i'm now releasing my application. It contain a simple http server, that must be always active! I prefer to ensure that the server remains active and continuing to provide http services, although there are bugs.
It's too weird?
:)

[Chris Kawa]

So your question basically is: "I wrote a buggy software. How can I make it work without fixing it?"
My answer is: "Sorry, I can't help you" ;)

[EDIT]: To give you a little more constructive answer: If you don't have comprehensive testing suite use some static analysis tool like "cppcheck":http://cppcheck.sourceforge.net/ It's very good at finding this kind of bugs so you should be able to detect and fix them quicker.

[xalisonx]

I do not seek a philosophical solution, but wonder if there is a technical solution.

[Chris Kawa]

The best technical solution is to fix the bugs. As I mentioned earlier - you can surround your code with try/catch and ignore such errors, but they will often lead to more serious problems like data corruption or security vulnerabilities (e.g. writing out of array bounds, uninitialized variables pointing to "secret" data and many others). Considering your software is an http server I'm guessing that's not something you want to risk.

In any case I wouldn't risk keeping such software running after a failure occurs. The state it's in is indeterminable. Just let it crash (log stuff if you can but crash anyway).
A crude workaround is to create a service that would monitor if your server is running and restart it when it crashes. It's a little like putting a band-aid on a broken leg but might be a temporary solution until you can fix the soft.

[xalisonx]

Ok Chris, I try to explain better.
I'm new with Qt.
With other languages (ie. C#, Java, Javascript also) you can catch and manage exceptions like null pointer reference, and so on.

How in Qt? Is possible or not?? This is my question.

This code doesn't works.

@try {
QJsonObject *o = NULL;
qDebug()<<o->empty();
}
catch(std::exception ex) {
// don't catch!!!
}
catch(...) {
// don't catch!!!
}@

The reply may be simple:

1. NO, no solution for you :( Qt is unable to catch this.
2. YES, this is solution :) ...............

[Chris Kawa]

The reply is: NOne of these apply ;) Or in other words: yes and no. You can do it but you never should.

bq. How in Qt? Is possible or not?? This is my question.

I can only repeat until you get it - Qt doesn't throw exceptions. Also, your example has nothing to do with Qt. You could change QJsonObject to Foo and it would still be the same case. The only exception thrown here would be (if it's enabled by compiler switches) by the platform runtime, not Qt.

There is no null pointer exception in c++ language. Dereferencing a null pointer is a software bug in c++, an undefined behavior and you can't reliably catch it (apart from platform specific runtime extensions). You should never try it because there's no virtual machine that will save you like in java or sandbox like in javascript.

The proper way to do this in c++ is:
@
QJsonObject* object = //get it from somewhere
if(object)
qDebug() << object->empty();
@

[xalisonx]

Yay Chris, now I got the power! :) thanks for the explanation