mirror of
https://github.com/boostorg/outcome.git
synced 2026-02-18 14:22:08 +00:00
107 lines
6.5 KiB
HTML
107 lines
6.5 KiB
HTML
<!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 id="boost-common-heading-doc" style="background: #574D74 url('../../images/header-bg.png') repeat-x top left;">
|
|
<div class="heading-inner" style="background: url('../../images/header-fg.png') no-repeat top left;">
|
|
<div class="heading-placard"></div>
|
|
|
|
<h1 class="heading-title">
|
|
<a href="../../">
|
|
<img src="../../images/space.png" alt="Boost C++ Libraries" class="heading-logo" />
|
|
<span class="heading-boost">Boost</span>
|
|
<span class="heading-cpplibraries">C++ Libraries</span>
|
|
</a>
|
|
</h1>
|
|
|
|
<p class="heading-quote">
|
|
<q>...one of the most highly
|
|
regarded and expertly designed C++ library projects in the
|
|
world.</q> <span class="heading-attribution">— <a href=
|
|
"http://www.gotw.ca/" class="external">Herb Sutter</a> and <a href=
|
|
"http://en.wikipedia.org/wiki/Andrei_Alexandrescu" class="external">Andrei
|
|
Alexandrescu</a>, <a href=
|
|
"http://safari.awprofessional.com/?XmlId=0321113586" class="external">C++
|
|
Coding Standards</a></span></p>
|
|
</div>
|
|
</div>
|
|
<div id="boost-common-heading-doc-spacer"></div>
|
|
<div class="spirit-nav">
|
|
<a accesskey="p" href="../../tutorial/interop.html"><img src="../../images/prev.png" alt="Prev"></a>
|
|
<a accesskey="u" href="../../tutorial/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/interop/value-or-error.html"><img src="../../images/next.png" alt="Next"></a></div><div id="content">
|
|
<div class="titlepage"><div><div><h2 class="title" style="clear: both">Incommensurate E types</h2></div></div></div>
|
|
<p>Back in the tutorial section on Default Actions, we studied a likely very common
|
|
initial choice of <code>E</code> type: <a href="../../default-actions/enums">a strongly typed enum</a>.
|
|
We saw how by marking up strongly typed enums to tell the C++ standard library
|
|
what they are, they gain implicit convertibility into <code>std::error_code</code>, and we
|
|
then pointed out that you might as well now 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 the Default Actions of <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 complication 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: December 05, 2018 at 14:18:52 UTC</small></p>
|
|
<hr>
|
|
<div class="spirit-nav">
|
|
<a accesskey="p" href="../../tutorial/interop.html"><img src="../../images/prev.png" alt="Prev"></a>
|
|
<a accesskey="u" href="../../tutorial/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/interop/value-or-error.html"><img src="../../images/next.png" alt="Next"></a></div></body>
|
|
</html>
|