[Qt5-feedback] new Qt5 - great! - but: What about exceptions?

[BRM]

----- Original Message ----
> From: Frans Klaver <fransklaver at gmail.com>
> To: qt5-feedback at qt.nokia.com
> Sent: Tue, May 17, 2011 7:58:38 AM
> Subject: Re: [Qt5-feedback] new Qt5 - great! - but: What about exceptions?
> 
> On Tue, May 17, 2011 at 12:32 PM, Thiago Macieira <thiago at kde.org> wrote:
> > No, errors  need to be caught where they make sense.
> 
> That might just be equal to what  I meant.


It is; but Exceptions don't enable that - or at least don't encourage it.
That is the problem.

In all the various mechanisms for errors that I've come across, nothing works as 
well or makes people who use the APIs as well as building in methods of directly 
returning errors, and having the discipline to handle them immediately.

That is - functions that can have errors (e.g. f(x) = 1+2 does not generate an 
error, but if 'x' is a pointer and the pointer is NULL then it could) - need to 
have return codes that can tell the caller there was an error. Whether it is a 
simple boolean value for pass/fail, or a more complicated integral value like 
errno. In either case, programmers making use of the API need to be disciplined 
enough to check for the error and handle it.

Exceptions, on the other hand, encourage passing the buck as opposed to handling 
the error. For example, most users of Exceptions will open a connection to a 
database via the database API. If the database API generates an error, it might 
try to handle one variant of the exception but then pass the buck on all the 
rest. So when the database changes and the exception goes from "can't open 
network connection" (which it might have handled) to "can't find file" (which 
the programmer didn't expect to have to handle) then the exception gets passed 
up to the next layer which may have no clue what to do.

Error handling has nothing to do with Business Logic, and everything to do with 
good engineering - design and implementation. How you present the error to the 
user ultimately may occur in some applications to be part of the Business Logic, 
but in most it does not.

Ben