add PipelineError to capture exit code

[simonbyrne]

At the moment if a process fails and throws and error, there is no easy way to capture the exit code. The only other option is to run asynchronously and manually check (but then there is no easy way to throw an error...)

[simonbyrne]

Alternative to #26719

[JeffBezanson]

This should probably be a separate commit.

[simonbyrne]

Same PR okay?

[JeffBezanson]

Sure.

[JeffBezanson]

On the triage call it was noted that we might not want to actually use this style of error handling --- we can use wait=false, call wait on the process object, and then look at the exit code.

[simonbyrne]

In that case, should we export pipeline_error (or some sort of "throw error based on exit code" function?)

[JeffBezanson]

Maybe call it ProcessError since it has to do with process failure, and there is not necessarily a pipeline (might be 1 process)?

[StefanKarpinski]

Some bikeshedding: this could be called ProcessError since there's always some process that failed, and it's not always wrapping a pipeline. Maybe this structure:

struct ProcessError <: Exception
    process::Process
    pipeline::Union{Nothing,Pipeline}
end

Where the process is the process that failed and pipeline is the pipeline that it belonged to, if any.

[StefanKarpinski]

Triage is in favor of the better error type; @vtjnash doesn't want to use it for this particular use case, favoring a run(..., wait=false) call with a status check instead.

[simonbyrne]

@vtjnash doesn't want to use it for this particular use case, favoring a run(..., wait=false) call with a status check instead.

So similar to #26719?

[simonbyrne]

Can't you have multiple failures in the one pipeline?

[StefanKarpinski]

Can't you have multiple failures in the one pipeline?

Sure, that's why it has the pipeline field as well.

[simonbyrne]

Okay, but which one do we report in the process field?

[StefanKarpinski]

The first one that failed, presumably.

[JeffBezanson]

This can still be done but doesn't block 1.0.

[simonbyrne]

Looks like it was fixed by #27900