LEWGI Cologne: Investigate non-exception based error-handling and its implications on the process creation API.

[JeffGarland]

So as we've probably already discussed, I believe the crux of this comes down to not using the process constructor to spawn. So you'd always have to construct and then call a function like 'spawn' which could report an error with a return. Something along the lines of

  process p (...);
  optional<system_error> err = p.spawn(); //noexcept

Things I can see against this:

1. inconsistent with std::thread or std::jthread api design
2. if the invariants of process are violated in constructor exception is more consistent
3. makes user code longer - trivially, but still

[eliaskosunen]

We could consider having a throwing constructor, and a non-throwing free factory function:

class process {
   friend make_process(..., std::error_code& errc);
public:
    process(...);
};

// Can't be noexcept with the Lakos rule :(
process make_process(..., std::error_code& errc);

[JeffGarland]

Yes -- that fixes the invariant part. Still I find the consistency with thread to be compelling -- I don't want to have to 'remember' that that process api is distinct.

And I think there's nothing preventing user writing the analog to make_process:

  pair<process, error_code> safe_process( process& p, ... ) 
 {   
    error_code ec;
    try { 
      p = process( ... );
    }
   catch (system_error& se) {
      ec = se.code();
   }
  return {p, ec};
 }

Note this I believe is enabled by the ability to default construct -- and actually that constructor is will be noexcept:

    // An empty process is similar to a default constructed thread. It holds an empty 
    // handle and is a place holder for a process that is to be launched later.
    process() = default;

[JeffGarland]

I've added a section to discuss the tradeoffs