12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626364656667686970717273747576777879808182 |
- <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
- <html><meta http-equiv="Content-Type" content="text/html; charset=utf-8">
- <title>Incommensurate E types - Boost.Outcome documentation</title>
- <link rel="stylesheet" href="../../../css/boost.css" type="text/css">
- <meta name="generator" content="Hugo 0.52 with Boostdoc theme">
- <meta name="viewport" content="width=device-width,initial-scale=1.0"/>
- <link rel="icon" href="../../../images/favicon.ico" type="image/ico"/>
- <body><div class="spirit-nav">
- <a accesskey="p" href="../../../tutorial/advanced/interop.html"><img src="../../../images/prev.png" alt="Prev"></a>
- <a accesskey="u" href="../../../tutorial/advanced/interop.html"><img src="../../../images/up.png" alt="Up"></a>
- <a accesskey="h" href="../../../index.html"><img src="../../../images/home.png" alt="Home"></a><a accesskey="n" href="../../../tutorial/advanced/interop/value-or-error.html"><img src="../../../images/next.png" alt="Next"></a></div><div id="content">
- <div class="titlepage"><div><div><h1 style="clear: both">Incommensurate E types</h1></div></div></div>
- <p>Back in the essential tutorial section on <code>result</code>, we studied a likely very common
- initial choice of <code>E</code> type: <a href="../../../tutorial/essential/result.html">a strongly typed enum</a>.
- We saw how <a href="../../../motivation/plug_error_code.html">by marking up strongly typed enums to tell the C++ standard library
- what they are</a>, they gain implicit convertibility into <code>std::error_code</code>, and we
- then pointed out that you might as well now always set <code>E = std::error_code</code>, as that
- comes with the enormous advantage that you can use the boilerplate saving
- <code>BOOST_OUTCOME_TRY</code> macro when the <code>E</code> type is always the same.</p>
- <p>We thus strongly recommend to users that for any given piece of code, always
- using the same <code>E</code> type across the codebase is very wise, except where you explicitly want
- to prevent implicit propagation of failure up a call stack e.g. local failures in
- some domain specific piece of code.</p>
- <p>However it is unreasonable to expect that any non-trivial codebase can make do
- with <code>E = std::error_code</code>. This is why Outcome allows you to use <a href="../../payload">custom <code>E</code>
- types which carry payload</a> in addition to an error code, yet
- still have that custom type treated as if a <code>std::error_code</code>, including <a href="../../payload/copy_file3">lazy custom exception
- throw synthesis</a>.</p>
- <p>All this is good, but if library A uses <code>result<T, libraryA::failure_info></code>,
- and library B uses <code>result<T, libraryB::error_info></code> and so on, there becomes
- a problem for the application writer who is bringing in these third party
- dependencies and tying them together into an application. As a general rule,
- each third party library author will not have built in explicit interoperation
- support for unknown other third party libraries. The problem therefore lands
- with the application writer.</p>
- <p>The application writer has one of three choices:</p>
- <ol>
- <li><p>In the application, the form of result used is <code>result<T, std::variant<E1, E2, ...>></code>
- where <code>E1</code>, <code>E2</code> … are the failure types for every third party library
- in use in the application. This has the advantage of preserving the original
- information exactly, but comes with a certain amount of use inconvenience
- and maybe excessive coupling between high level layers and implementation detail.</p></li>
- <li><p>One can translate/map the third party’s failure type into the application’s
- failure type at the point of the failure
- exiting the third party library and entering the application. One might do
- this, say, with a C preprocessor macro wrapping every invocation of the third
- party API from the application. This approach may lose the original failure detail,
- or mis-map under certain circumstances if the mapping between the two systems
- is not one-one.</p></li>
- <li><p>One can type erase the third party’s failure type into some application
- failure type, which can later be reconstituted if necessary. This is the cleanest
- solution with the least coupling issues and no problems with mis-mapping, but
- it almost certainly requires the use of <code>malloc</code>, which the previous two did not.</p></li>
- </ol>
- <p>Things get even more complicated in the presence of callbacks. If in the
- callback you supply to library A, you call library B, you may need to insert
- switch statement maps or other mechanisms to convert library B’s failures into
- something library A can understand, and then somehow extract that out – preferably
- without loss of original information – into the application’s failure handling
- mechanism if library A subsequently returns failure as well. This implies
- transmitting state by which to track these interrelated pieces of failure data.</p>
- <p>Let us see what Outcome can do to help the application writer address some of these
- issues, next.</p>
- </div><p><small>Last revised: February 09, 2019 at 15:18:26 UTC</small></p>
- <hr>
- <div class="spirit-nav">
- <a accesskey="p" href="../../../tutorial/advanced/interop.html"><img src="../../../images/prev.png" alt="Prev"></a>
- <a accesskey="u" href="../../../tutorial/advanced/interop.html"><img src="../../../images/up.png" alt="Up"></a>
- <a accesskey="h" href="../../../index.html"><img src="../../../images/home.png" alt="Home"></a><a accesskey="n" href="../../../tutorial/advanced/interop/value-or-error.html"><img src="../../../images/next.png" alt="Next"></a></div></body>
- </html>
|