| It isn't possible today for a plan author to formally signal to callers that the plan failed (surfacing an error without requiring the caller to provide distinct (and not bound by convention) code paths for "ok" vs. "error". E.g.
$results = case ($plan_result = run_plan('mymodule::myplan', |
'_catch_errors' => true, |
)) { |
Error: { $plan_result.details['result_set'] } |
default: { $plan_result } |
}
|
Ideally, a caller should be able to expect a consistent return type regardless of whether or not the plan failed; just like a caller can always expect an object of type ResultSet to be returned from run_task. Allow for a moment that a plan always returns an object of type PlanResult. If this is true, we can generalize success/failure based on $pr.ok, just as ResultSet handling can be based on $rs.ok. If a PlanResult is not ok (it failed), we can generalize access to the error raised via e.g. $pr.error. The PlanResult object can define a standard interface to data returned by a plan, such as defining a .value method, and the index method (.[]) for easy access to returned data keys. A caller could then simplify their code to e.g.
$result = run_plan('mymodule::myplan', |
_catch_errors => true, |
) |
|
run_task('mymodule::next_step, $result.value.ok_set)
|
OR
OR
if !$result.ok { |
# handle it |
}
|
...etc., depending on what the plan author chooses to return. Being able to rely on the datatype returned by run_plan greatly simplifies how plan authors can call and deal with the results from running other plans. |
