Re: Using C++ exceptions instead of error_state

[Rik]

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)
>>   ...
>> else
>>    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
>> variable.
>
> 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.

--Rik