2017-01-25 14:56 GMT+01:00 Niall Douglas
If your irritation is now improved, what do you think of the new and completely rewritten for a third time tutorial part A at https://ned14.github.io/boost.outcome/md_doc_md_02-tutorial_a.html. Part A is 100% a tutorial on LEWG Expected and has nothing to do with Outcome at all. Part B will be on why you shouldn't do all the things you think you should do with expected
, and why to use Outcome instead. Part B is still a work in progress.
Ok, so I had a short glimpse at Part A. Actually, the first thing I did was
to scroll down to the example showing how I will be using this library.
Again, I feel uncomfortable about the choice of the example (so I changed
the irritation into non-comfort). The situations that are tested, I would
classify them as precondition violations, and I wouldn't think of checking
them in return value. If this was a real program, and I didn't trust the
values of x and y, I can check the preconditions prior to invoking
functions:
```
double op(double x, double y)
{
if (y == 0.0) // or "close
{
std::cerr << "PANIC: MatchResult::DivisionByZero" << std::endl;
std::terminate();
}
double ratio = unchecked::div(x, y);
if (ratio < 0.0)
{
std::cerr << "PANIC: MatchResult::NegativeLogarithm" << std::endl;
std::terminate();
}
double ln = unchecked::ln(ratio);
if (ln < 0.0)
{
std::cerr << "PANIC: MatchResult::NegativeSquareRoot" << std::endl;
std::terminate();
}
return checked::sqrt(ln);
}
```
I mean, if it is equally easy to check the condition before and after the
function, it is better to do it before, and I do not have to "pollute" the
return value with potential error conditions. I think the value of these
expected<> types becomes clear, when we cannot see the erroneous situation
from the arguments. Maybe a better illustration of expected<> with a code
would the following situation:
Upon closing the application, I store its state in a text file. When I
reopen the application the next time, I load the state from the file. Here
is the function:
expected