Quote Originally Posted by wysota View Post
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.