Exception Handling, Throwing Exception and Try/Catch blocks
-
[quote author="cazador7907" date="1292202586"]How do I define my own error number? I might have missed it in my searches but I cannot find any guidance in the Qt documentation.[/quote]
If you are not familiar with error numbers:@
/// this is a enumeration of all error conditions "I currently know"
enum MyRunTimeErrors {
MY_SUCCESS_CODE,
MY_INDEX_OUT_OF_BOUNDS,
MY_NULL_POINTER_NOT_ALLOWED,
MY_INVALID_RANGE
};/// this is a placeholder function handling all "currently known" errors
void test() {
const int error = doSomethingNonTrivial(); // in this call several errors can occur
switch (error) {
code MY_SUCCESS_CODE:
// All went good :)
// Make anything else here...
break;code MY_INDEX_OUT_OF_BOUNDS: // Handle index not inside the valid bounds of an array (a list) break; code MY_NULL_POINTER_NOT_ALLOWED: // Handle unsuported null pointer break; code MY_INVALID_RANGE: // Handle numeric range miss, maybe by an input break; default: // Oops, who (me ??) did something wrong, and especially: WHAT? traceError("Internal Error: Unknown Error detected #%d", error); break;
}
}
@..., leave this out, study exception handling today!
The exception-based way is much better, since you can group error conditions and decide from case to case how specific your handling should be. You get a second channel for error detection, error transmission, error handling. Exceptions are not used yet in Qt, but (my glass ball says:) it will (it has to) come that we can switch them on optionally.
-
Hi Wolf, exceptions or not is a matter of taste, as Volker said. I suggest using error number more than exceptions. If you want to ignore the error, that's easy with error numbers not with exceptions. If the exceptions are not 100% cleard efined in the throws, it's hgard to know, which exceptions are thrown and should be catched. And in many places, where exceptions are used for errors, I see only this:
@
try
{
// do some stuff that might throw an exception
}
catch(...)
{
// do something
}
@And then, exceptions do NOT make sense.
-
When you find this style of exception handling "used" everywhere in your project
@
catch (...) { /* indeed: do NOTHING */ }
@
...then it's a sure sign of ignorance. I think those, who try to skip analysis, understanding and classification of errors, will never succeed in error handling. Skipping default in switch is equivalent to catch all clauses anywhere in the code.Of course, you can classify errors using numeric codes. But that's hard work.
-
Wolf P., again it's just matter of taste. For me errno way is much simplier error handling than exception-way.
-
For me too. If I want to handle the errors, I can handle one or more errors in the same way, in the same block of code (via switch, if, whatever).
-
That I have to accept.
Here something more interesting, I've found googling for "Qt exception exec":
"Qt: Throw exceptions from signals and slots":http://rohieb.wordpress.com/2010/07/08/qt-throw-exceptions-from-signals-and-slots/
For those who like exceptions it may be interesting ,if not already known. -
This means, no exceptions from slots and event handlers. Or re-implement that function, but you can't handle them in the main if they are thrown in the event loop. And what to do in event loops in threads?
-
(1) Generally, it seems not to be possible to throw exceptions through the libraries of the operating system.
(2) I'm not yet familiar with threads in Qt. What is the standard event loop for an additional thread? -
QEventLoop :-))
And throwing exceptions via libraries is not the problem. But perhaps the QApplication eventloop catches them? I didn't look at the QtCode for that up to now. -
I catch the exceptions in the methods, where I call the lib's functions. In my special case, there is no event loop that can make things bad.
-
Gerolf, QEventLoop has no signals and no virtual function, so... In this issue I need to familiarize myself first...
(and: I don't think that you can throw an exception through a binary dynamic link library (with a C API).) -
You're right. C does not provide exceptions. You would have to write a C++ wrapper that adds this and that probably makes the API more OO-like (that's what the ImageMagick/GraphicsMagick guys did).
-
[quote author="Volker" date="1292253297"]I catch the exceptions in the methods, where I call the lib's functions. In my special case, there is no event loop that can make things bad. [/quote] You're right. But If you forget to handle a particular exception your program crashes.
Of course it should be terminated immidiately, but gracefully. -
That part of the program is only very small. Basically only one class that uses the lib, and every exception that can be thrown is caught and handled in our case. But I agree, that can be hard to handle all together.
I personally like the concept of exceptions - you can throw them and whoever is responsible catches them and handles the condition. Althoug I never used them in C++ on my own (only in Java), as there are too many pitfalls at the moment.
-
Dlls can use exceptions, wolf, if they are C++ dlls. And I don't think, that you create C dlls if you are using Qt, do you? My dlls are normally C++ dlls which export C++ classes. There it could be done, but I don't do it.
And QEventLoop handles asynchronous signals, as QueuedSignals are in fact events :-) -
For clarity: I am not in the least interested to write DLLs in C myself. I meant pre-existing DLLs. Try to throw an exception in a Windows callback and you'll see what I was talking about. (Sometimes you have to code against a Windows API.)
I'm sorry that I have expressed this somewhat misleading.
-
@DenisKormalev said in Exception Handling, Throwing Exception and Try/Catch blocks:
exception-way or errno-way are equal ways. I can't say that one is better than another. They are simply different. Qt chose errno-way at the beginning and uses it now.
NOT THEY ARE NOT!
exception are structured way of both rise the error and handle the error
return codes do not dictate how you handle (the mechansim) , you might even not handle it!, try doing the same with exceptions ;) -
@giesbert tier down the application obviously ... exceptions are exceptional ...