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

[Carnë Draug]

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

> I think I would use validateattributes and let the backtrace that gets
dumped automatically show that the error was generated in validateattributes,
but the calling function was my_function.m. Isn't that how Matlab handles it?

Yes. But my point is that if core functions use validateattributes for input
check, and if core functions let validateattributes throw the error, then they
will use the validateattributes error ids. Since that happens, then we should
have validateattributes throw the error ids that we want the core functions to
throw. So this is not about what error ids validateattributes should throw.
This about what error ids Octave core should throw.

Also, if they are the error ids that core functions throw, then they should be
documented in the Octave manual or in the help text for error ids (and not in
validateattributes help text).

It all boils down to: do we want Octave core functions to throw error ids with
this level of detail? Or do we want the error id to be just "invalid-input"?

I think we should only throw "invalid-input" for two reasons.

First reason is that there's no hierarchy in error ids, no class system (or at
least not yet in Octave). We can't catch all errors that have id of
"expected-X" by catching "invalid-input".  Because of that, it would be more
useful to have them all throw the same error id. "invalid-input" sounds good
to me, but I don't care much for another wording.

The other reason is I find error ids to not be that useful to handle
programatically.  And if the error ids are only useful if they are read by a
person, then why have them at all? we already have the error message for that,
no need for the error id as well.  In this specific case, it is likely that
input fails for multiple reasons, for example, wrong size and non-negative. 
The error id is then not enough to explain all that went wrong.

    _______________________________________________________

Reply to this item at:

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

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