45 lines
2.5 KiB
Plaintext
45 lines
2.5 KiB
Plaintext
[/
|
|
Copyright (c) Vladimir Batov 2009-2014
|
|
Distributed under the Boost Software License, Version 1.0.
|
|
See copy at http://www.boost.org/LICENSE_1_0.txt.
|
|
]
|
|
|
|
[section:error_detection Better Error Detection]
|
|
|
|
[import ../example/getting_serious.cpp]
|
|
|
|
[getting_serious_example1]
|
|
|
|
The code above is straightforward and self-explanatory but, unfortunately, strictly speaking, is not entirely deterministic as -1 might be the result of a conversion failure or the successful conversion of the "-1" string. Still, in reality "spare" values are quite often available outside the valid\/sensible range to indicate conversion failures. If so, such deployment might be adequate without introducing non-deterministic behavior. Alternatively, it might be not that uncommon to ignore conversion failures altogether and to simply log the failure and to proceed with the supplied fallback value.
|
|
|
|
Applications outside these mentioned categories still require conversion failure reliably detected and processed accordingly. The `boost::lexical_cast`'s answer is to throw on failure and ['Boost.Convert] supports that behavior as well:
|
|
|
|
[getting_serious_example2]
|
|
|
|
However, to cater for a wider range of program-flow variations, ['Boost.Convert] adds the flexibility of
|
|
|
|
* delaying the moment when the conversion-failure exception is actually thrown or
|
|
* avoiding the exception altogether.
|
|
|
|
[getting_serious_example3]
|
|
|
|
Now [@boost:/libs/optional/index.html `boost::optional`] steps forward as the actual type returned by `boost::convert()` which until now we avoided by immediately calling its value-accessor methods:
|
|
|
|
int i1 = boost::convert<int>(str1, cnv).value();
|
|
int i2 = boost::convert<int>(str2, cnv).value_or(fallback_value);
|
|
int i3 = boost::convert<int>(str3, cnv).value_or_eval(fallback_function);
|
|
|
|
Still, from the user perspective, `boost::lexical_cast` processes failure in a somewhat one-dimensional non-negotiable manner. `boost::convert` takes a more flexible approach, provides choice and leaves the decision to the user. It probably is not unimaginable that, on the library level, propagating the conversion-failure exception might be the only sensible response. On the application level though, in my personal experience, the choice has overwhelmingly been to handle conversion failures locally, i.e. avoiding conversion-failure exception propagation or, better still, avoiding exceptions altogether with program flows similar to:
|
|
|
|
[getting_serious_example4]
|
|
|
|
and
|
|
|
|
[getting_serious_example5]
|
|
[getting_serious_example6]
|
|
|
|
[endsect] [/section:error_detection Better Error Detection]
|
|
|
|
|
|
|