devn00b
/
EQ2EMu


			
							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&lt;T, libraryA::failure_info&gt;</code>,
and library B uses <code>result&lt;T, libraryB::error_info&gt;</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&lt;T, std::variant&lt;E1, E2, ...&gt;&gt;</code>
where <code>E1</code>, <code>E2</code> &hellip; 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&rsquo;s failure type into the application&rsquo;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&rsquo;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&rsquo;s failures into
something library A can understand, and then somehow extract that out &ndash; preferably
without loss of original information &ndash; into the application&rsquo;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>