# Design Decisions
## Why this crate?
When using `Command` it is very easy to forget that the `Result`
returned by `output()` does not represent if the command was
successful but just if it did run, possible unsuccessful. E.g.
a typlical error is to see something like this in a `build.rs`
script:
```
// bad, you have to check the value
// of the exit status, too
Command::new("cmd123")
.arg("--with_spelling_errorr")
.status()
.expect("cmd123 failed");
```
In which case `cmd123` would terminate with a non-successful exit
status but `status()` will still return `Ok(ExitStatus)`. Which
makes sense but especially in case of build scripts it is extremely
common that a non-successful exit status is also seen as failure.
This crate first makes it less probable to forget checking the
exit status and secondly removes part of the "check the exit status"
code.
## Why a custom Output
In std `Output` is a type bundling the collected output of stderr, stdout
and the exit status. But such a struct is not needed for this crate.
Firstly `Ok` is only returned if the exit status was successful i.e.
available and not equal 0. Which is a single value and therefore the `Ok`
site does not have to contain a exit status. On the `Err` side on the other
side there is no reason to close couple the output and exit status.
Secondly `ExitStatus` does not have a constructor (except on unix
with the `ExitStatusExt`) which means testing a method taking
`Output` as parameter can be bothersome.
## Why implement CheckedCommand/CheckedChild this way?
Both `CheckedCommand` and `CheckedChild` are structs with a single
field wrapping of type `Command`/`Child`. A naive approach would use
`Deref` to expose the inner structs methods, but this would defete the
purpose of this wrappers, which is to "hide away" the original `status`,
`output` implementations. And while shadowing the methods exposed by deref
with methods of the same name is possible it is also slightly brittle.
As `Command` and `Child` don't have neither to manny methods nor
are expected to gain (many) new ones I decided to create a explicit
wrapper, which "manually" proxies all unchanged methods. This also
has the big benefit that if `Command` or `Child` gains a new method,
which would have to be replaced by a checked version (like `Child::try_wait`)
it won't be automatically exposed. Because if it would automatically expose
the method it is easy to overlook that this method is not replaced with a checked
variation. With the current implementation the method would only by available by
explicitly getting a reference to the inner type, making clear that it isn't wrapped.