[Octave-bug-tracker] [bug #48439] validateattributes throws errors without IDs

[Carnë Draug]

Follow-up Comment #18, bug #48439 (project octave):

Carlo de Falco on comment #17:
> [...] and I don't see your arguments as a good enough reason for Octave to
deviate from Matlab compatibility here.

There is no Matlab compatibility to keep because our error are Octave:X
instead of Matlab:X. Also, Matlab error ids are now
Matlab:FunctionName:invalidX

>From Matlab docs:
> The function name becomes part of the error identifier.
> 
> MException.last.identifier
> 
> ans =
> 
> MATLAB:findVolume:invalidType

Lachlan on comment #1:
> Carlo, it would be nice if the error ID for a faulty call to this function
was different from a valid call that stated that the attribute is not valid.
>
> You don't need to limit yourself to the existing error IDs, do you?

Kind of. Since this function can be used by octave core functions to validate
their input, then it needs to be limited to Octave core error ids.  But that
list can be increased.

The error id refers to what caused an error with the most detailed error id
documented.  What caused an error was an invalid argument and that's
independent of whether that invalid argument was for validateattributes or
some other function.  Adding more details to the error (expected-1d,
expected-string, etc) as proposed does not fix the issue because if those
error id are added, then they should also be used by validateattributes
itself.

If this is really necessary, then it should be done the other way around,
i.e., have validateattributes throw its own specific error id if called
incorrectly. Something like "octave:validateattributes-incorrect-usage".  It
addresses the issue of being able to distinguish the two causes and doesn't
reduce the usefulness of the error ids. 

However, I'm not really convinced that will be necessary. error ids are used
when handling the error programatically (otherwise one would use the error
message where the function name is mentioned). I can't imagine anyone
programming error handling for validateattributes incorrect usage.

Carlo on comment #2
> The error is an invalid input argument in both cases, and the error message
does specify whether the invalid arg was passed to validateattributes itself
or to a function using validateattributes internally, so I think that part is
not that bad ...

Agreed

> [...]
> I am not limited to existing IDs but I remember previous discussions about
not introducing too many different IDs and this would probably introduce a
lot.

You're right. This has been discussed before. Let's not introduce loads of new
error ids. If there's too many without an exception subclass they become
useless.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?48439>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/