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.
exception-error-diffs-v3.txt