Suggested Error Handling

[Max Yaffe]

Dear forum,

I've been looking in the docs for an error handling method but haven't seen one. In the past (Pre-Qt) I've used a system of error return values defined by Microsoft, but I don't know if that is portable.

I know Qt avoids the C++ exception handling system so is there an accepted, consistent, portable error handling approach you can suggest?
Thanks,
Max

[wysota]

Qt doesn't avoid exceptions. It just doesn't use them which doesn't mean you can't use them in your applications. In general Qt tends to return true/false values or some kind of state value from its methods, but you don't have to follow the behaviour in your classes.

[Max Yaffe]

Thanks for the reply.

I like to avoid exceptions, too, for many of the same reasons as Qt does. I tend to return a status code. I was just wondering if there is a standard way of organizing status codes in Qt.

Max

[wysota]

true/false and enums

[33333]

Qt doesn't avoid exceptions. It just doesn't use them which doesn't mean you can't use them in your applications. In general Qt tends to return true/false values or some kind of state value from its methods, but you don't have to follow the behaviour in your classes.

The thing I find frustrating about trying to be like Qt and avoiding exceptions is constructors - which don't have a return value. Exceptions are the recommended C++ way of dealing with failures in constructors - AFAIK. The problem with not using exceptions in the constructor is if you don't, your initialization is not atomic. Using exceptions there is a strong contract between the client and constructor: Either you initialize successfully or you blow up. Without exceptions you have to do your init() in two phases. The issue here is clients can forget they have to do that. To guard against that you have to add a guard to all your public functions with a `am_i_initialized()` check. That's extra work, and the coder can forget to do that too.

Long story short; with respect to exceptions, I *personally* have made a rule that I'm allowed to use exceptions in constructors only. I'm seeing how it pans out .

But there is another piece to the puzzle; actually handling erroneous conditions consistently on an app wide basis. Exceptions are a good way to delegate error handling up the call chain towards a global handler. But the model does not really fit event drive programing anyway. The execution is not really hierarchical - you hit the event loop after a few short steps up the call chain.

I'm still investigating, but right now, in a single threaded app, I'm wrapping the call to exec() in a ~global exception handler (that I think should catch all exceptions??) to cover exceptions off, and looking at another global mechanism for raising errors. I'm thinking I might just use qFatal() for that...

P.S. I wanted to ask a similar question so advice/thoughts appreciated.

Thanks.

[jefftee]

The thing I find frustrating about trying to be like Qt and avoiding exceptions is constructors - which don't have a return value.

I don't do anything in the default constructor or destructor for this very reason. I use the constructor initialization lists to do basic variable initialization (NULL for pointer, 0 for int, etc) and then I add init() and cleanup() methods for each class that I implement so that I can determine whether or not initialization or cleanup has been successful.

I personally don't use exception handling and prefer that methods return success/failure indicators... I use either true/false for simple success/failure and use enums if I need to return different success/error values.

Hope that helps.

Jeff

[Infinity]

@33333: I think this FAQ will answer some of your questions: http://www.parashift.com/c++-faq-lite/exceptions.html