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

[Hugo Parente Lima]

On Tuesday 17 May 2011 10:53:46 BRM wrote:
> ----- 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

So let's avoid to use a knife because it can cut off our fingers and let still 
use the hammer that can completely smash them, just because we are used to. I 
already saw this pointless argument against O.O. and C++, now about 
exceptions, nice... but my fingers still useless after all this, smashed or 
cut off.

This makes no sense to me, however I agree about avoiding exceptions on Qt, 
not by the nature of exceptions but by the mess caused by the use of 
exceptions in C++ dynamic libraries.... in other words, if the reasons to not 
have exception in Qt is all clear and well defined by Qt developers, why still 
discussing about this?

Regards 

-- 
Hugo Parente Lima
INdT - Instituto Nokia de Tecnologia
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
Url : http://lists.qt.nokia.com/pipermail/qt5-feedback/attachments/20110517/1f037416/attachment.bin