On Tue, May 17, 2011 at 3:53 PM, BRM <[email protected]> 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. _______________________________________________ Qt5-feedback mailing list [email protected] http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
