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

[Frans Klaver]

Let's start off with the notion that I'm not a big fan of exceptions in C++.

On Tue, May 17, 2011 at 10:51 AM, BRM <bm_witness at yahoo.com> wrote:

> Exceptions make programmers extra lazy. Errors need to be handled as close to
> the source of the error as possible to have truly robust and reliable code.
> That may mean that you need to define error interfaces to retrieve error
> information, and to propagate the errors up through those interfaces - but
> that's part of  writing good, robust, reliable code.

Lazy is a good feat of programmers. If you're lazy enough, you're
going to do a lot of work to be able to stay lazy in the future. To
say that exceptions make your code error prone may be true, but having
to check a lot of return values is more error prone than throwing
exceptions to signal errors. I've seen code improve _because_ we
introduced exceptions. We took out piles of macros that would catch a
return value and send it through to the caller and then even fail to
provide exact enough information to locate the issue.

> Exceptions, on the other hand, by definition push the work of handling the error
> off to someone else; and if no one handles it (b/c they think it is someone
> else's job or that it is too unlikely to happen) then it will simply crash the
> program - something that should never be acceptable.

Errors should be handled there where your business logic knows how to
handle them. That is true for both error codes and exceptions. The pro
for exceptions is that you don't clutter your lower level business
logic with a lot of error checking, the con is that C++ exceptions are
messy at best.

Given the nature of an error, sometimes it _is_ better to crash the
program. I liked the reasoning in
http://labs.qt.nokia.com/2010/08/11/apology-of-the-null-pointer/

>  In other words, they are
> too easy to abuse and should be avoided like GOTO is - used where it absolutely
> must be, but otherwise ignored.

Return values obviously cannot be abused, ignored, postponed,
deferred, denied and whatnot.

At certain times exceptions lead to cleaner code. Of course for
previously given reasons the exceptions shouldn't cross dll
boundaries, but to dismiss them as evil and to be avoided at all time
is a bit harsh and arguably short-sighted.