Would it be a good idea to use Failure and FailureQ in own code

Question

Since version 10 (at least 10.0.2 but I think 10.0.0) there is Failure and since version 10.2 there is also FailureQ. As often the documentation is somewhat vague and says "Failure is generated by Interpreter and related functions.".

To me it looks like Failure is not more than a symbol which can be used as the head of an expression in a return value or an argument to Throw which indicates that something went wrong. A Failure expressions is expected to have two arguments, the first being a tag to be able to match against, the second an association as a second argument which can hold additional information about what went wrong. That is very much what an Exception object in other languages would contain and has obvious applications.

The question is whether it would be a good idea to rely on these symbols for my own code or whether it is more safe to run my own "exceptions" package. I currently don't see any disadvantage of just using Failure in that way which would save me from providing a new symbol in an additional package which creates dependencies and I could also take advantage of an already defined FailureQ and - less important but nice to have - formatting of these failure-expressions.

Any thoughts and experience out there? Any recommendations from WRI known to be published anywhere?

Answer 1

What I personally usually do is to still use $Failed / exceptions when a returned $Failed / thrown exception can't be used constructively when handled / caught, other than issuing the right message. In some cases, however, the application logic requires to do more than that. In particular, certain data associated with the state right before the failure may be needed to handle the error correctly. In cases like that, Failure seems a good match.

There are at least two different modes in which Failure can be used. One is that in the case of a failure, you return the Failure object to the calling function, instead of just returning $Failed. This would allow to return not just the fact of the failure, but also error code. Another is to use Throw like

Throw[Failure[...], tag]

combining Failure and exceptions. This is needed in the same situations where exceptions are typically used, but Failure allows us to bring more information along with an exception. Along similar lines, Failure can also be abused constructively to have a non-local control flow, even in cases which aren't hard failures - I did this a few times in inner functions not facing the user.

Surely one can place association inside an exception tag, doing essentially the same:

Throw[$Failed, error[label, assoc]]

or something like that, but I feel that using Failure in cases like this is semantically cleaner.

All in all, I don't see any reason not to use Failure in cases when one needs to bring additional information to the function that must handle the error, be it in return mode or exception mode.

Answer 2

I made a package called functionArgumentFailure which uses Failure to handle functions which have been called with wrong arguments.

   Needs["functionArgumentFailure`"]

   ClearAll[test];

   test[a_?StringQ] := 1;
   test[args___] := functionArgumentFailure[test, args]; 

Here is an example where the function test has been called with not enough arguments:

I think Failure is a nice way to give feedback about what went wrong, it can be much more informative than a message. It might also be nice to use it together with the new Success Symbol which has been introduced in 11.3.