[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Using C++ exceptions instead of error_state

From: John W. Eaton
Subject: Re: Using C++ exceptions instead of error_state
Date: Wed, 23 Sep 2015 15:47:57 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.5.0

On 12/22/2014 11:32 PM, Rik wrote:
On 12/22/2014 02:11 PM, John W. Eaton wrote:
On 12/22/2014 12:05 PM, Rik wrote:
On 12/22/2014 03:03 AM, jwe wrote:

Thanks for the detailed comments.
1) Are there functions which set error_state, but that do not generate
error messages and thus do not shortcircuit?

I'm thinking of patterns in input validation of the form

std::string arg = arg(0).string_value ();
if (! error_state)
    error ("ARG 0 must be a string");

I think code like this currently generates two error messages if
conversion to a string is not possible.  One from the string_value function
and one from the other call to error.  The only way error_state was
supposed to be set was with a call to error, and I don't think there were
many (any?) calls with empty message arguments in core Octave.
This could be simplified to a single line if the string_value() function
issues an error when the input cannot be coerced to a string.  However,
it might make coding difficult if you don't know which functions will
issue errors and shortcircuit and which will merely set the error_state

With the changes I'm proposing, no function will set error_state.  All
error handling will happen with exceptions.  Although not enforced, the
only way that error_state was supposed to be set previously was by calling
some form of error function.  Of course any function could call error, but
if you didn't account for error_state, you could easily keep processing
using invalid data.  Now you won't be able to do that unless you explicitly
catch the exception.  However, I don't think we want to have a lot of
try/catch blocks just for specific error messages.

This is how I was hoping it would behave.  I think this change will be
quite useful for preventing Garbage In/Garbage Out calculations.  Currently
it is too easy to proceed with invalid data by forgetting to check
error_state after every function call.

I've revisited this change and updated my patch so that it applies to the current sources. I'm attaching the new version to this message.

To summarize, the idea is to change the error function to throw an exception so that we can eliminate the use of the global error_state variable over time (likely a very long time).

Is there any objection to going ahead with this change?


Attachment: exception-error-diffs-v3.txt
Description: Text document

reply via email to

[Prev in Thread] Current Thread [Next in Thread]