Skip to main content

Fail

rascal-0.30.1

Synopsis

Let the current alternative of a pattern match fail.

Syntax

fail;

fail Label;

Description

A fail statement is only allowed in statements that are controlled by the outcome of a pattern match:

  • The Patterns in a Pattern With Action in Switch or Visit statement controls the statements in the action part.
  • The test (expression) of a While or Do statement controls the statements in the body part.
  • The test (expressions) of a For statement control the statements in the body part.
  • The formal parameter declaration of a Function.

The fail statement is associated with the innermost pattern match by which it is controlled, unless it has a label. For, While and If can have a label that fail can jump to, and function names can be used to fail the entire application of a function match. A failed function would backtrack to the next overloaded candidate.

When fail is executed:

  • If the associated pattern has more alternatives, the next alternative is explored,
  • otherwise the pattern as a whole fails. In the case of switch or visit this means that the next case will be tried. For while, do and for, this implies that any bindings caused by the pattern are undone and that the next alternative in the test is tried; otherwise the loop is terminated. ** For a function call it means that the next function declaration (or the default one) is tried.

Examples

Here is an example. It uses a fail for the case that no unsorted element can be found in the list of numbers. As a result, the whole case fails and the default case is used.

rascal>import IO;
ok
rascal>public list[int] sort(list[int] numbers){
>>>>>>> switch(numbers){
>>>>>>> case [*int nums1, int p, int q, *int nums2]:
>>>>>>> if(p > q){
>>>>>>> return sort(nums1 + [q, p] + nums2);
>>>>>>> } else {
>>>>>>> fail;
>>>>>>> }
>>>>>>> default: return numbers;
>>>>>>> }
>>>>>>>}
list[int] (list[int]): function(|prompt:///|(0,252,<1,0>,<11,1>))
rascal>sort([10, 1, 5, 3]);
list[int]: [1,3,5,10]

Benefits

  • fail offers direct programmeable influence on backtracking behavior

Pitfalls

  • fail breaks stack-trace-based debugging because the failed call may have been in the past.