[Qt5-feedback] new Qt5 - great! - but: What about exceptions?
Frans Klaver
fransklaver at gmail.com
Tue May 17 16:18:18 CEST 2011
On Tue, May 17, 2011 at 3:53 PM, BRM <bm_witness at yahoo.com> wrote:
> 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.
Matter of taste mostly which approach works best. As far as discipline
goes, both approaches lean on developers having the discipline to
properly handle the errors in a way that is both responsible and
logical. Handling errors immediately is only useful if you know what
to do. If "knowing what to do" means you know that you have to
translate the thing in order to be useful at a higher level, so be it,
but that still boils down to the same principle for both exceptions
and return values. Handle errors where you know what to do with them.
Oftentimes, yes, this will be immediately; sometimes, you will have to
let it slide a level higher.
> 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.
In either case it again boils down to error handling discipline.
Whether by exception or by return value, a developer has to properly
handle them. In my opinion, these cases are not 'exceptional' enough
to raise an exception in the first place, but that is an entirely
different discussion.
More information about the Qt5-feedback
mailing list