"Emil Dotchevski" <emildotchevski@gmail.com> wrote in message news:c72e33ce0910291442k3a989264v25a367c19a4cdc05@mail.gmail.com...
On Thu, Oct 29, 2009 at 2:20 PM, Michael Fawcett <michael.fawcett@gmail.com> wrote:
On Thu, Oct 29, 2009 at 5:07 PM, Emil Dotchevski <emildotchevski@gmail.com> wrote:
On Thu, Oct 29, 2009 at 1:46 PM, Stewart, Robert <Robert.Stewart@sig.com> wrote:
It's simple:
if (error-not-checked && !std::uncaught_exception()) { throw something; }
I've read that article before. To me it only seemed applicable to destructors that actually did something, like a rollback. For an object that does nothing in its destructor, do you think Herb's arguments still apply?
The point is that a destructor could call a function that returns this sneaky error code object, and end up throwing an exception. You can argue that this is a bug, but that's exactly why it is evil -- for anything but a trivial toy example, such code can't reasonably be tested because it is very difficult to reproduce the conditions that could possibly lead to abort().
imho gotw-047 does not apply here: - the "unsound" objection does not apply here because with "smart_error_codes" it is not the callee (T::~T in the example) that decides whether to throw or not...it is the caller...and the caller is the (U) destructor (i.e. the writer of the destructor) that knows that it does not want throw...and with "smart_error_codes" it does not have to use try-catch to swallow/handle the exception it simply "inspects" the returned "smart_error_code" and thus both disables exceptions and handles a possible error condition... (maybe i shoudn't have used the exact example from gotw-047 because it uses a destructor in a destructor and destructors cannot return values...but i hope the argument is still clear) - the "unmoral" objection does not apply here because the caller is not forced to handle both flavours of error reporting...the user is given the "power" to choose which method suits best...and it also forces the programmers to check for errors, whichever method is used ;) imho your "evil" objection also does not apply because if a "smart error code" object is "sneaky" then so is the T object in the gotw-047 example...in other words any function that can possibly throw falls into the category of a "sneaky object" (because it can possibly throw in a destructor and cause abort() to be called...and because it can only possibly throw it is also not be "reasonably tested")... ...i would actually claim quite to the contrary...the "smart error code" approach would actually give you a simpler way to disable exceptions in a destructor while still handling errors...
Why not just pick a behavior -- throw on error, or don't throw on error -- whichever is correct?
exactly...that's what a "smartened error code" gives you...pick a behavior on a call by call basis ;) -- "That men do not learn very much from the lessons of history is the most important of all the lessons of history." Aldous Huxley