Boost.Process V2 missing error_code constructor

[csk-ableton]

Boost.Process generally offers throwing and non-throwing overloads.

The constructor of boost::process::v2::process is missing an overload that takes an error_code instance. The following code does not compile:

boost::system::error_code ec;
boost::process::v2::process process{ctx, ec, "/usr/bin/cp", {"source.txt", "target.txt"}};

Looks like these constructors are simply missing and could easily forward ec to default_process_launcher? v1 offered such constructor overloads.

[klemens-morgenstern]

That's a deliberate choice. I can't think of any other library having constructors that take an error_code to indicate an error.
Rather, the common pattern is that a constructor should throw on error.

In other libraries, the ec always gets passsed into a function, that returns an empty thingy if ec is set. You can do the above easily enough by just using the default_launcher directly.

boost::system::error_code ec;
auto process = boost::process::v2::default_launcher()(ctx, ec, "/usr/bin/cp", {"source.txt", "target.txt"});

[csk-ableton]

Hi @klemens-morgenstern,

thanks for the quick response!

That's a deliberate choice. I can't think of any other library having constructors that take an error_code to indicate an error. Rather, the common pattern is that a constructor should throw on error.

You are totally right that it's not very common. There is filesystem::directory_iterator but it has an obvious state it can go into in case of an error.

A better example might be boost::asio::basic_socket_acceptor and basic_stream_file which don't take an error_code in their constructors but they do provide non-throwing constructors that don't open the socket/stream and allow to do that using a method afterwards.

process has a non-throwing default constructor but no way to later launch the process as far as I can see? Maybe introducing launch methods that take an error_code could be an option? That would make the API for clients that want to avoid exceptions more obvious than the example you provided and is consistent with the design in Asio.

What do you think about documenting the exception behavior in the constructors? Given the API generally offers non-throwing versions, one could assume the lack of such an API means that the constructor doesn't throw and lead to surprises / crashes, especially given the code that throws is hidden behind an indirection.