Re: Using exceptions in the core

[Mike Miller]

On Wed, Oct 7, 2015 at 11:09:49 -0400, John W. Eaton wrote:
> If adding these extra member functions seems like clutter, then the next
> best option seems to me to be a regular function like this:
>
>   std::string url = get_string (args(0), "URL must be a string");
>
> But is that really better than just defining the extractor as a member
> function?

Only if we want to decide, for example, that the default behavior for
all extractors shall be to throw an exception in case of failure to
convert, and then this decorator function would do the "safe"
conversion.

But this is about the same as having, say

  std::string octave_value::string_value (); // this one throws an exception
  std::string octave_value::safe_string_value (const std::string& msg) nothrow;

Do we want to give the user the option of handling the exception or
having error() called for them?

> If the bool argument of the current string_value extractor doesn't actually
> do anything, then I'm not sure it matters much.  We wouldn't suddenly (and
> silently) be making code behave differently, we'd just be requiring people
> to remove irrelevant arguments from function calls. Disruptive, yes, but
> fairly simple to change.

I think this would be a net positive.

> Does any code that we know of derive from octave_base_value, overload the
> string_value extractor, and make the bool argument do something?

I usually go to codesearch.debian.net to answer things like this. It
tells me that outside of Octave itself, only swig and plplot (which is
using swig) have overrides of the string_value(bool) method (search
for regexp "string_value *\( *bool"). Neither one actually does
anything with the force argument.

-- 
mike