new keyword "error" for stoping a workflow with an error message

We have been running into situations where the input data doesn’t fit the assumptions of the workflow. while might cause a downstream error to happen on its own, the error message accompanying this event usually doesn’t point at the correct source of the problem.

This could be resolved by some if statements in the wdl, running some sanity checks on the input, but then there is no way to gracefully and informatively fail. An error keyword would allow authors to fail a workflow without having to spin up a vm that fails (i.e. returns error code 1) in order to inform the user of the true reason for failure.

[pshapiro4broad]

Personally I don’t see a great value in the form

  Int y = if x > 5 then x else error("Input x was not good")

Which is syntactic sugar for

  if (!(x > 5)) {
    error("Input x was not good")
  }
  Int y = x

Adding this form would require addressing the concept of functions that never return, like error(), and what type they are. The gain here is not worth the extra effort, IMO.

I agree that form like error(String) makes more sense than error(String, Boolean)

[cjllanwarne]

@rhpvorderman I think the “boolean” part could be handled by the existing if { } and if / then / else constructs. I agree that supplying a message along with the error would be nice.

Eg in workflows?

workflow foo {
  call task_a
  if (!task_a.good_result) {
    error("task_a's result was not good")
  }
}

And in tasks?

task foo {
  input {
    Int x
  }
  Int y = if x > 5 then x else error("Input x was not good")
  command {
    echo "I can guarantee you that ~{y} is greater than 5!"
  }
}