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 <[email protected]> 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. _______________________________________________ Qt5-feedback mailing list [email protected] http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
