Error handling libraries and proposals
Last week it was brought to my attention that there are currently 5 different libraries and proposals for dealing with the problem of reporting errors from noexcept functions, so I thought it would be useful to update the Noexcept documentation with a short section comparing all the different designs: https://zajo.github.io/boost-noexcept/#alternatives.
On 10/07/2017 18:07, Emil Dotchevski via Boost wrote:
Last week it was brought to my attention that there are currently 5 different libraries and proposals for dealing with the problem of reporting errors from noexcept functions, so I thought it would be useful to update the Noexcept documentation with a short section comparing all the different designs: https://zajo.github.io/boost-noexcept/#alternatives.
Some notes on Outcome v2 related to your now out of date comparison: * result and outcome can now be error type customised, same as all the other libraries. For example, outcome<void, void, void> is legal, though unusable. * result and outcome are struct-like, some of the others are variant-like. * I have compiled out by default an implementation of P0252 as well, but it can be reenabled if I decide it's wise later. Your table would be better if it listed the items in the headers rather than by number, but for Outcome v2 the new values are: yes, yes, yes, yes, no, yes, yes, yes. (v2 result is specifically designed to be C struct layout compatible) Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
On Mon, Jul 10, 2017 at 10:44 AM, Niall Douglas via Boost < boost@lists.boost.org> wrote:
On 10/07/2017 18:07, Emil Dotchevski via Boost wrote:
Last week it was brought to my attention that there are currently 5 different libraries and proposals for dealing with the problem of reporting errors from noexcept functions, so I thought it would be useful to update the Noexcept documentation with a short section comparing all the different designs: https://zajo.github.io/boost-noexcept/#alternatives.
Some notes on Outcome v2 related to your now out of date comparison:
Thank you for letting me know that the Outcome design has changed, again. :)
* result and outcome can now be error type customised, same as all the other libraries.
Not all the other libraries. The Noexcept design does not force you specify the possible error types for each function because, as we have learned from the exception specifications fiasco, in non-trivial cases (usually in generic library code) it is impossible to know what errors may be returned by lower level functions. If the error handling library forces you to list them anyway, in such use cases the two choices you're left with is to translate (which is prone to errors and usually imperfect), or some form of catch-all, e.g. unique_ptr<void>. The reality is that not everyone is or will be using only std::error_code; ideally, functions should be able to forward errors from lower level code intact.
For example, outcome<void, void, void> is legal, though unusable.
What would be the meaning of outcome<void,void>?
, but for Outcome v2 the new values are:
yes, yes, yes, yes, no, yes, yes, yes.
To me, your note that Outcome is struct-like rather than variant-like means that it does not have strict value-or-error semantics, so the last one would be "no". Also, could you expand on how Outcome can propagate errors from a C-style callback or across language boundaries? I'm referring to use cases like these: https://zajo.github.io/boost-noexcept/#example_lua
Thank you for letting me know that the Outcome design has changed, again. :)
It's only changed as per peer review feedback. If you trawl all 800+ emails and drag out a consensus view of the community, you end up with highly inoffensive Outcome v2. Well, apart from copying std::variant's constructor design, that's on me, but I think cloning the C++ standard is an okay design choice.
For example, outcome<void, void, void> is legal, though unusable.
What would be the meaning of outcome<void,void>?
outcome<void, void> would equal outcome<void, void, std::exception_ptr>. Such an object can store a void or an exception_ptr. Or rather, have the state of a void or an exception_ptr.
, but for Outcome v2 the new values are:
yes, yes, yes, yes, no, yes, yes, yes.
To me, your note that Outcome is struct-like rather than variant-like means that it does not have strict value-or-error semantics, so the last one would be "no".
Unless you enable the positive status support manually, a strict enforcement of value or error is made. There is no longer an empty state, so you literally must choose either valued, or errored. Anything else won't compile.
Also, could you expand on how Outcome can propagate errors from a C-style callback or across language boundaries? I'm referring to use cases like these: https://zajo.github.io/boost-noexcept/#example_lua
I specifically personally need result to be C layout compatible so AFIO can have C SWIG bindings. Outcome v1 was C layout compatible too, but v2 is even more so because it's just a struct of the form: struct { T value; unsigned flags; EC error; }; ... and bit 0 of the unsigned means a T is present, and bit 2 means an EC is present. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
On Mon, Jul 10, 2017 at 1:36 PM, Niall Douglas via Boost < boost@lists.boost.org> wrote:
outcome<void, void> would equal outcome<void, void, std::exception_ptr>.
Such an object can store a void or an exception_ptr. Or rather, have the state of a void or an exception_ptr.
So, if I understand correctly, the second void means exception_ptr? Why isn't it outcome<void,exception_ptr>? What are the semantic differences between e.g. expected<int,exception_ptr> and outcome<int,void>?
, but for Outcome v2 the new values are:
yes, yes, yes, yes, no, yes, yes, yes.
To me, your note that Outcome is struct-like rather than variant-like means that it does not have strict value-or-error semantics, so the last one would be "no".
Unless you enable the positive status support manually, a strict enforcement of value or error is made.
Ah, so this means that it is optional, like in Noexcept. I'll reflect that in the comparison table.
Also, could you expand on how Outcome can propagate errors from a C-style callback or across language boundaries? I'm referring to use cases like these: https://zajo.github.io/boost-noexcept/#example_lua
I specifically personally need result to be C layout compatible so AFIO can have C SWIG bindings. Outcome v1 was C layout compatible too, but v2 is even more so because it's just a struct of the form:
struct { T value; unsigned flags; EC error; };
... and bit 0 of the unsigned means a T is present, and bit 2 means an EC is present.
It seems that here you are making the case I've been making, that in general std::error_code is not sufficient, that an error-handling library must be able to propagate errors of user-defined types, and not only through an exception_ptr. I also think it is a good idea to be C-compatible, but from the above it isn't clear to me how that works. Could you please post a complete example, specifically how can outcome<T> propagate errors from a C (not C++) API? That said, if you look at the example I linked, you'll see that it is about more than just being C-layout compatible, but also being able to propagate an error from a third-party C-style callback which does not return your struct. In case I'm missing something, could you post the outcome<T> version of the example I linked?
On 10/07/2017 22:06, Emil Dotchevski via Boost wrote:
On Mon, Jul 10, 2017 at 1:36 PM, Niall Douglas via Boost < boost@lists.boost.org> wrote:
outcome<void, void> would equal outcome<void, void, std::exception_ptr>.
Such an object can store a void or an exception_ptr. Or rather, have the state of a void or an exception_ptr.
So, if I understand correctly, the second void means exception_ptr? Why isn't it outcome<void,exception_ptr>? What are the semantic differences between e.g. expected<int,exception_ptr> and outcome<int,void>?
Are you confusing result and outcome? result<T, EC> outcome<T, EC, E|P> The default template parameters give exactly the same as with v1. But if say you chose `result<int, long>` or `outcome<int, long, std::string>` then that works too.
, but for Outcome v2 the new values are:
yes, yes, yes, yes, no, yes, yes, yes.
To me, your note that Outcome is struct-like rather than variant-like means that it does not have strict value-or-error semantics, so the last one would be "no".
Unless you enable the positive status support manually, a strict enforcement of value or error is made.
Ah, so this means that it is optional, like in Noexcept. I'll reflect that in the comparison table.
Eh, well, it defaults to strict enforcement of either, it can only be different if you change a macro. And as the code matures I may make the strict enforcement mandatory.
Also, could you expand on how Outcome can propagate errors from a C-style callback or across language boundaries? I'm referring to use cases like these: https://zajo.github.io/boost-noexcept/#example_lua
I specifically personally need result to be C layout compatible so AFIO can have C SWIG bindings. Outcome v1 was C layout compatible too, but v2 is even more so because it's just a struct of the form:
struct { T value; unsigned flags; EC error; };
... and bit 0 of the unsigned means a T is present, and bit 2 means an EC is present.
It seems that here you are making the case I've been making, that in general std::error_code is not sufficient, that an error-handling library must be able to propagate errors of user-defined types, and not only through an exception_ptr.
I did take into account your feedback during the review, yes, and I've definitely thrown you some meat in v2.
I also think it is a good idea to be C-compatible, but from the above it isn't clear to me how that works. Could you please post a complete example, specifically how can outcome<T> propagate errors from a C (not C++) API?
That it cannot do. You could store it into TLS the same as you're doing behind the scenes though. Outcome v2 is far more barebones than v1 was. It does pretty much nothing above the absolute bare minimum.
That said, if you look at the example I linked, you'll see that it is about more than just being C-layout compatible, but also being able to propagate an error from a third-party C-style callback which does not return your struct. In case I'm missing something, could you post the outcome<T> version of the example I linked?
You'd declare some TLS storage, same as you do internally, and reference that. So say: ``` static thread_local result<void, do_work_error> state; int do_work( lua_State * L ) noexcept { bool success=rand()%2; if( success ) return lua_pushnumber(L,42), 1; else { state = do_work_error{}; return lua_error(L); } } result<int, do_work_error> call_lua( lua_State * L ) noexcept { lua_getfield( L, LUA_GLOBALSINDEX, "call_do_work" ); if( int err=lua_pcall(L,0,1,0) ) { lua_pop(L,1); return state; } else { int answer=lua_tonumber(L,-1); lua_pop(L,1); return answer; } } ``` Which is almost as succinct as yours. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
On Mon, Jul 10, 2017 at 4:19 PM, Niall Douglas via Boost < boost@lists.boost.org> wrote:
On 10/07/2017 22:06, Emil Dotchevski via Boost wrote:
On Mon, Jul 10, 2017 at 1:36 PM, Niall Douglas via Boost < boost@lists.boost.org> wrote:
outcome<void, void> would equal outcome<void, void, std::exception_ptr>.
Such an object can store a void or an exception_ptr. Or rather, have the state of a void or an exception_ptr.
So, if I understand correctly, the second void means exception_ptr? Why isn't it outcome<void,exception_ptr>? What are the semantic differences between e.g. expected<int,exception_ptr> and outcome<int,void>?
Are you confusing result and outcome?
result<T, EC>
outcome<T, EC, E|P>
The default template parameters give exactly the same as with v1. But if say you chose `result<int, long>` or `outcome<int, long, std::string>` then that works too.
I still don't understand what does it mean to use void. I don't understand what this means: "outcome<void, void> would equal outcome<void, void, std::exception_ptr>"
, but for Outcome v2 the new values are:
yes, yes, yes, yes, no, yes, yes, yes.
To me, your note that Outcome is struct-like rather than variant-like means that it does not have strict value-or-error semantics, so the
last
one would be "no".
Unless you enable the positive status support manually, a strict enforcement of value or error is made.
Ah, so this means that it is optional, like in Noexcept. I'll reflect that in the comparison table.
Eh, well, it defaults to strict enforcement of either, it can only be different if you change a macro. And as the code matures I may make the strict enforcement mandatory.
I think that this is a key design decision. So is whether or not you have to enumerate the possible error types. Take this for what it's worth, but the earlier outcome design was a lot more focused. Reading the documentation, some of it sounded like evangelization of std::error_code, so the conclusion I drew was that the idea is that you don't specify the error types because you should only be using std::error_code, except that in the real world you might get an exception from somewhere, in which case outcome lets you stuff a std::exception_ptr into it too. That makes sense, even if I think that it is not practical to assume that everyone will jump on the std::error_code train. On the other hand, expected<T,E> (Vicente) says no, std::error_code is not the only option so this should be a template parameter. On top of that, expected<T,E...> (Peter) says well, at the very least you might get an exception from somewhere so you have to be able to have e.g. expected<T,std::error_code,std::exception_ptr>, so we'll take more than a single E. The other significant difference you introduced post-review was that outcome no longer had strict value-or-error semantics. This too helped set it apart. But now, and it may be just me, but I am confused. What exactly is the difference between outcome and the two flavors of expected we have? Is it essentially the same as expected<T,E...>, except that in outcome the strict value-or-error semantics (that you may remove later) are optional?
Also, could you expand on how Outcome can propagate errors from a C-style callback or across language boundaries? I'm referring to use cases like these: https://zajo.github.io/boost-noexcept/#example_lua
I specifically personally need result to be C layout compatible so AFIO can have C SWIG bindings. Outcome v1 was C layout compatible too, but v2 is even more so because it's just a struct of the form:
struct { T value; unsigned flags; EC error; };
... and bit 0 of the unsigned means a T is present, and bit 2 means an EC is present.
It seems that here you are making the case I've been making, that in general std::error_code is not sufficient, that an error-handling library must be able to propagate errors of user-defined types, and not only through an exception_ptr.
I did take into account your feedback during the review, yes, and I've definitely thrown you some meat in v2.
Ha, I'm honored. :)
I also think it is a good idea to be C-compatible, but from the above it isn't clear to me how that works. Could you please post a complete example, specifically how can outcome<T> propagate errors from a C (not C++) API?
That it cannot do. You could store it into TLS the same as you're doing behind the scenes though. Outcome v2 is far more barebones than v1 was. It does pretty much nothing above the absolute bare minimum.
That said, if you look at the example I linked, you'll see that it is about more than just being C-layout compatible, but also being able to propagate an error from a third-party C-style callback which does not return your struct. In case I'm missing something, could you post the outcome<T> version of the example I linked?
You'd declare some TLS storage, same as you do internally, and reference that. So say:
``` static thread_local result<void, do_work_error> state;
int do_work( lua_State * L ) noexcept { bool success=rand()%2; if( success ) return lua_pushnumber(L,42), 1; else { state = do_work_error{}; return lua_error(L); } } result<int, do_work_error> call_lua( lua_State * L ) noexcept { lua_getfield( L, LUA_GLOBALSINDEX, "call_do_work" ); if( int err=lua_pcall(L,0,1,0) ) { lua_pop(L,1); return state; } else { int answer=lua_tonumber(L,-1); lua_pop(L,1); return answer; } } ```
Which is almost as succinct as yours.
This might be reasonable if it is a one-off thing, but consider that the general case is a bit more complicated, possibly involving different compilation units, and you do need to ensure that when the thread terminates "state" doesn't contain an error. It may or may not make sense to add something to that effect to Outcome. By the way, this illustrates that errors and successful return values are very different semantically, which is why at least sometimes it is necessary to find a different channel to pass errors out. At which point one must ask what is the downside of using TLS for the error object? What is the design rationale for insisting on stuffing errors into return values, moving them one level up at a time, when in reality only the reporting and the handling code care about the error? The benefits of always passing errors through TLS are 1) it effectively decouples successful results from error conditions, which in turn means that only the error-reporting and the error-handling code are coupled with the error object or its type; and 2) it doesn't require the enumeration of all possible error types that a function may "return" (I'll once again refer the reader to exception specifications as to why that is a bad idea). The reason why not requiring the enumeration is linked to TLS use is that it requires the storage to be "large enough", which is perhaps too large to stuff into a return value (since we can't assume that a dynamic allocation is permissible.)
Are you confusing result and outcome?
result<T, EC>
outcome<T, EC, E|P>
The default template parameters give exactly the same as with v1. But if say you chose `result<int, long>` or `outcome<int, long, std::string>` then that works too.
I still don't understand what does it mean to use void. I don't understand what this means:
"outcome<void, void> would equal outcome<void, void, std::exception_ptr>"
The default declaration for outcome is: ``` template < class R, class S = std::error_code, class P = std::exception_ptr, class NoValuePolicy = policy::default_outcome_policy<R, S, P>
requires (std::is_void<EC>::value || std::is_default_constructible<EC>::value) && (std::is_void<P>::value || std::is_default_constructible<P>::value) class [[nodiscard]] outcome; ``` Yay the Concepts TS. Anyway, therefore `outcome<void, void>` equals `outcome<void, void, std::exception_ptr>`. Does it make sense now? (I think you'll find the synposis at https://ned14.github.io/outcome/synopsis/outcome/ clears everything up for you)
Take this for what it's worth, but the earlier outcome design was a lot more focused.
You may be forgetting my initial claims of a "multi-modal" design. v1 wore many hats. v2 has no head, so it cannot wear a hat.
Reading the documentation, some of it sounded like evangelization of std::error_code, so the conclusion I drew was that the idea is that you don't specify the error types because you should only be using std::error_code, except that in the real world you might get an exception from somewhere, in which case outcome lets you stuff a std::exception_ptr into it too. That makes sense, even if I think that it is not practical to assume that everyone will jump on the std::error_code train.
That was purely a simplifying narrative which was taken due to continuing Reddit confusion. v1 always could do far more that the tutorial suggested. You could, in fact, customise any of the types to anything you liked so long as you met an error_code or an exception_ptr contract. v2 now concepts matches instead. If you feed it a type matching an error_code concept, it treats it as an error code, otherwise it does not. Same for exception_ptr. Thus `outcome<int, int, int>` is legal, but unusable, because you cannot construct one without resorting to UB.
On the other hand, expected<T,E> (Vicente) says no, std::error_code is not the only option so this should be a template parameter. On top of that, expected<T,E...> (Peter) says well, at the very least you might get an exception from somewhere so you have to be able to have e.g. expected<T,std::error_code,std::exception_ptr>, so we'll take more than a single E.
v2 was designed to dovetail into Expected neatly. It's basically a hugely simplified and thus much faster to compile subset. That should allow Expected to take on much more monadic stuff, if Vicente prefers.
The other significant difference you introduced post-review was that outcome no longer had strict value-or-error semantics. This too helped set it apart.
In the default configuration, outcome<T, EC, E|P> is only strictly value-or-error, value-or-exception, or value-or-error+exception.
But now, and it may be just me, but I am confused. What exactly is the difference between outcome and the two flavors of expected we have? Is it essentially the same as expected<T,E...>, except that in outcome the strict value-or-error semantics (that you may remove later) are optional?
It's a low level subset. Struct-based storage, not variant-based. Fast. Lightweight. ABI stable. But not rich, it's a barebones type.
This might be reasonable if it is a one-off thing, but consider that the general case is a bit more complicated, possibly involving different compilation units, and you do need to ensure that when the thread terminates "state" doesn't contain an error. It may or may not make sense to add something to that effect to Outcome.
v2 is designed to be subclassed into localised implementations in a local namespace, which is a new thing. So it's very easy to add additional behaviours and features to your localised implementation, whilst retaining the cross-ABI interoperability between many localised implementations. v2 only provides the raw building block. What you do with it after it totally up to you. For example, one could build your Noexcept library with it quite easily, and thus "plug in" to Expected, P0650 etc.
By the way, this illustrates that errors and successful return values are very different semantically, which is why at least sometimes it is necessary to find a different channel to pass errors out. At which point one must ask what is the downside of using TLS for the error object? What is the design rationale for insisting on stuffing errors into return values, moving them one level up at a time, when in reality only the reporting and the handling code care about the error?
The benefits of always passing errors through TLS are 1) it effectively decouples successful results from error conditions, which in turn means that only the error-reporting and the error-handling code are coupled with the error object or its type; and 2) it doesn't require the enumeration of all possible error types that a function may "return" (I'll once again refer the reader to exception specifications as to why that is a bad idea). The reason why not requiring the enumeration is linked to TLS use is that it requires the storage to be "large enough", which is perhaps too large to stuff into a return value (since we can't assume that a dynamic allocation is permissible.)
v2 Outcome is way lower level than any of that. It's a raw vocabulary type, pure and simple, nothing provided other than absolute bare minimum. Ready to act as a foundation stone for bigger stuff. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
On Mon, Jul 10, 2017 at 5:58 PM, Niall Douglas via Boost < boost@lists.boost.org> wrote:
Are you confusing result and outcome?
result<T, EC>
outcome<T, EC, E|P>
The default template parameters give exactly the same as with v1. But if say you chose `result<int, long>` or `outcome<int, long, std::string>` then that works too.
I still don't understand what does it mean to use void. I don't understand what this means:
"outcome<void, void> would equal outcome<void, void, std::exception_ptr>"
The default declaration for outcome is:
``` template < class R, class S = std::error_code, class P = std::exception_ptr, class NoValuePolicy = policy::default_outcome_policy<R, S, P>
requires (std::is_void<EC>::value || std::is_default_constructible<EC>::value) && (std::is_void<P>::value || std::is_default_constructible<P>::value) class [[nodiscard]] outcome; ```
Yay the Concepts TS. Anyway, therefore `outcome<void, void>` equals `outcome<void, void, std::exception_ptr>`.
Does it make sense now?
No. Why would I pass void for S or P? By the way, such policy-based design is probably not a ideal for error-handling library return types, for the same reason shared_ptr<T> is better than Alexandrescu's policy-based smart pointer, and for the same reason function<T> (as it is now standardized) is better than function<T,A> (as it was in Boost initially, before I fixed it): it leads to much increased coupling, and ABI incompatibilities. The thing is, error objects, like smart pointers and function objects, need to be as frictionless as possible when crossing API boundaries, and policy-based designs work directly against that goal.
Take this for what it's worth, but the earlier outcome design was a lot
more focused.
You may be forgetting my initial claims of a "multi-modal" design. v1 wore many hats. v2 has no head, so it cannot wear a hat.
I'm afraid my reading is that you're shifting important design decisions to the user, who has (by definition) lower qualifications in the domain of error handling. Flexibility is not always good, after all we all have a C++ compiler and can handle errors with all the flexibility we need -- without an error handling library.
Reading the documentation, some of it sounded like evangelization of std::error_code, so the conclusion I drew was that the idea is that you don't specify the error types because you should only be using std::error_code, except that in the real world you might get an exception from somewhere, in which case outcome lets you stuff a std::exception_ptr into it too. That makes sense, even if I think that it is not practical to assume that everyone will jump on the std::error_code train.
That was purely a simplifying narrative which was taken due to continuing Reddit confusion. v1 always could do far more that the tutorial suggested. You could, in fact, customise any of the types to anything you liked so long as you met an error_code or an exception_ptr contract.
I know. That makes sense, it's crystal clear.
v2 now concepts matches instead. If you feed it a type matching an error_code concept, it treats it as an error code, otherwise it does not. Same for exception_ptr. Thus `outcome<int, int, int>` is legal, but unusable, because you cannot construct one without resorting to UB.
Assuming we agree that passing int for the P makes no sense at all: 1. Could you show a practical case that illustrates the need for using anything but std::exception_ptr for P? 2. What is the benefit of P being semantically different from S? In other words, what is the difference/benefit of outcome<T,S,P> over expected<T,S,P>?
On the other hand, expected<T,E> (Vicente) says no, std::error_code is not the only option so this should be a template parameter. On top of that, expected<T,E...> (Peter) says well, at the very least you might get an exception from somewhere so you have to be able to have e.g. expected<T,std::error_code,std::exception_ptr>, so we'll take more than a single E.
v2 was designed to dovetail into Expected neatly. It's basically a hugely simplified and thus much faster to compile subset. That should allow Expected to take on much more monadic stuff, if Vicente prefers.
The other significant difference you introduced post-review was that outcome no longer had strict value-or-error semantics. This too helped set it apart.
In the default configuration, outcome<T, EC, E|P> is only strictly value-or-error, value-or-exception, or value-or-error+exception.
What other options are out there? What could I do with a struct with 3 members, which outcome "strictly" forbids?
But now, and it may be just me, but I am confused. What exactly is the difference between outcome and the two flavors of expected we have? Is it essentially the same as expected<T,E...>, except that in outcome the strict value-or-error semantics (that you may remove later) are optional?
It's a low level subset. Struct-based storage, not variant-based. Fast. Lightweight. ABI stable. But not rich, it's a barebones type.
Are you claiming that outcome<T,S,P> is faster than expected<T,S,P>? I don't see how could that be true. Perhaps I'm missing something. I'm also puzzled by the ABI stability claim. I mean, policy-based designs are only ABI-stable if most users use the same policies, which obviously defies the point of using policies.
This might be reasonable if it is a one-off thing, but consider that the general case is a bit more complicated, possibly involving different compilation units, and you do need to ensure that when the thread terminates "state" doesn't contain an error. It may or may not make sense to add something to that effect to Outcome.
v2 is designed to be subclassed into localised implementations in a local namespace, which is a new thing. So it's very easy to add additional behaviours and features to your localised implementation, whilst retaining the cross-ABI interoperability between many localised implementations.
v2 only provides the raw building block. What you do with it after it totally up to you.
The question is what's the value in using Outcome as a building block? Why would anyone bother, if using Outcome they're basically free to do whatever?
For example, one could build your Noexcept library with it quite easily, and thus "plug in" to Expected, P0650 etc.
I think Noexcept is a lot more lightweight than you think. The internal machinery it is based on (what I think you imagine your building block would replace) is about 500 lines, out of about 800.
The default declaration for outcome is:
``` template < class R, class S = std::error_code, class P = std::exception_ptr, class NoValuePolicy = policy::default_outcome_policy<R, S, P> > requires (std::is_void<EC>::value || std::is_default_constructible<EC>::value) && (std::is_void<P>::value || std::is_default_constructible<P>::value) class [[nodiscard]] outcome; ```
Yay the Concepts TS. Anyway, therefore `outcome<void, void>` equals `outcome<void, void, std::exception_ptr>`.
Does it make sense now?
No. Why would I pass void for S or P?
You wouldn't, as the voided types are not particularly useful. However as a fundamental vocabulary type highly useful in constexpr metaprogramming, being able to be configured with void is flexible. It can also be useful in internal macro boilerplate. And finally, Expected permits expected<void, void>, and seeing as I intend to offer explicit construction from any expected concept matching type, I need to support that as well.
By the way, such policy-based design is probably not a ideal for error-handling library return types, for the same reason shared_ptr<T> is better than Alexandrescu's policy-based smart pointer, and for the same reason function<T> (as it is now standardized) is better than function<T,A> (as it was in Boost initially, before I fixed it): it leads to much increased coupling, and ABI incompatibilities. The thing is, error objects, like smart pointers and function objects, need to be as frictionless as possible when crossing API boundaries, and policy-based designs work directly against that goal.
Completely agreed for a std::result<T, EC>, and any upcoming WG21 paper will have no NoValuePolicy template parameter. For a Boost library, it's an extended customisation point. Indeed, outcome<> actually reuses 90% of result<>'s implementation by supplying an outcome-ish no-value policy, so it saves me a ton of maintenance and copy and paste as well. So I'm calling it an internal implementation detail. Not to be worried about. And I agree with the general point made.
> Take this for what it's worth, but the earlier outcome design was a lot > more focused.
You may be forgetting my initial claims of a "multi-modal" design. v1 wore many hats. v2 has no head, so it cannot wear a hat.
I'm afraid my reading is that you're shifting important design decisions to the user, who has (by definition) lower qualifications in the domain of error handling. Flexibility is not always good, after all we all have a C++ compiler and can handle errors with all the flexibility we need -- without an error handling library.
v1 Outcome's core type was `template<class Policy> class basic_monad`. Everything user facing was typedefed to that with a default choice of policy. v2 similarly defaults the choice of policy. v2 is neither more nor less flexible. End users get the same degree of customisation power. Whether they use it wisely or not is up to them, as a vocabulary type it's not my remit to enforce good behaviour by library developers, just to encourage it. If they want to shoot themselves in the foot, they can.
v2 now concepts matches instead. If you feed it a type matching an error_code concept, it treats it as an error code, otherwise it does not. Same for exception_ptr. Thus `outcome<int, int, int>` is legal, but unusable, because you cannot construct one without resorting to UB.
Assuming we agree that passing int for the P makes no sense at all:
Not at all. There is nothing wrong with int as either an exception or a payload type. Some end user may want that for some reason. For the exact same reason, you can throw an int in C++. It can make sense.
1. Could you show a practical case that illustrates the need for using anything but std::exception_ptr for P?
The idea behind P is that when trait::is_exception_ptr<P> is false, then P is a payload type which provides additional information for your main EC failure type. So: outcome<Success, Failure, FailureInfo> Or more concretely: outcome<handle, std::error_code, std::filesystem::path> ... could return an open file handle on success, or an error code plus the failing path on failure.
2. What is the benefit of P being semantically different from S? In other words, what is the difference/benefit of outcome<T,S,P> over expected<T,S,P>?
Peter Dimov wanted the ability for the Filesystem TS to return the exception which would have been thrown in the error_code& overloads, so calling code can effectively filter whether to throw the exception or not. I can see that as a pretty useful use case, albeit expensive seeing as an exception_ptr is expensive to allocate. But still a reasonable half way house between a full throw-catch cycle and the currently metadata impoverished error_code& overloads. So outcome<handle, std::error_code, std::exception_ptr> does permit an error_code+exception_ptr construction, and you get exactly the desired functionality.
> The other significant difference you introduced post-review was that > outcome no longer had strict value-or-error semantics. This too helped set > it apart.
In the default configuration, outcome<T, EC, E|P> is only strictly value-or-error, value-or-exception, or value-or-error+exception.
What other options are out there? What could I do with a struct with 3 members, which outcome "strictly" forbids?
Things you can't do: * value + error * value + exception * value + error + exception
> But now, and it may be just me, but I am confused. What exactly is the > difference between outcome and the two flavors of expected we have? Is it > essentially the same as expected<T,E...>, except that in outcome the strict > value-or-error semantics (that you may remove later) are optional?
It's a low level subset. Struct-based storage, not variant-based. Fast. Lightweight. ABI stable. But not rich, it's a barebones type.
Are you claiming that outcome<T,S,P> is faster than expected<T,S,P>? I don't see how could that be true. Perhaps I'm missing something.
It should be to compile. Outcome is essentially nothing :)
I'm also puzzled by the ABI stability claim. I mean, policy-based designs are only ABI-stable if most users use the same policies, which obviously defies the point of using policies.
Remember Outcome permutes its namespace with the git SHA. So it's effectively randomised, and thus no symbol collisions can occur. The only ABI instability is thus the data layout, and as I've mentioned I've deliberately kept result's data layout C-struct compatible.
> This might be reasonable if it is a one-off thing, but consider that the > general case is a bit more complicated, possibly involving different > compilation units, and you do need to ensure that when the thread > terminates "state" doesn't contain an error. It may or may not make sense > to add something to that effect to Outcome.
v2 is designed to be subclassed into localised implementations in a local namespace, which is a new thing. So it's very easy to add additional behaviours and features to your localised implementation, whilst retaining the cross-ABI interoperability between many localised implementations.
v2 only provides the raw building block. What you do with it after it totally up to you.
The question is what's the value in using Outcome as a building block? Why would anyone bother, if using Outcome they're basically free to do whatever?
Using your logic, why use std::pair or std::tuple when a struct will do? Same argument.
For example, one could build your Noexcept library with it quite easily, and thus "plug in" to Expected, P0650 etc.
I think Noexcept is a lot more lightweight than you think. The internal machinery it is based on (what I think you imagine your building block would replace) is about 500 lines, out of about 800.
As you saw on SG14, using any black box library routines is always going to be a problem for the fixed latency user base. Your library is shorter than mine, but it calls unknown latency routines. Mine never does. You also impose TLS on your end users. Mine is much lower level than that, if end users wish to combine mine with TLS to achieve your library, they'll find it very easy. So why innovate for them? Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
Niall Douglas wrote:
Indeed, outcome<> actually reuses 90% of result<>'s implementation by supplying an outcome-ish no-value policy, so it saves me a ton of maintenance and copy and paste as well.
I would make outcome<> reuse 100% of result<>'s implementation, by stealing another page from your playbook: class extended_error_code { std::error_code e_; std::exception_ptr x_; }; template<class T> using outcome = result<T, extended_error_code>; I would also use union { T t; E e; } in result instead of a struct. :-)
On 11/07/2017 12:53, Peter Dimov via Boost wrote:
Niall Douglas wrote:
Indeed, outcome<> actually reuses 90% of result<>'s implementation by supplying an outcome-ish no-value policy, so it saves me a ton of maintenance and copy and paste as well.
I would make outcome<> reuse 100% of result<>'s implementation, by stealing another page from your playbook:
class extended_error_code { std::error_code e_; std::exception_ptr x_; };
template<class T> using outcome = result<T, extended_error_code>;
That may well happen yet. What held me back was that the universality of EC = error_code is very important in order to use TRY effectively. That's what led to the split design you see today, so you're basically exchanging some purity in the design for ease of programming. TRY is such a boon for not typing boilerplate. However it could be that dropping outcome and having result gain the ability to transform unrelated error types via some free function mechanism would be better. Indeed Andrzej asked for that exact same thing, I gave him one half of a solution.
I would also use union { T t; E e; } in result instead of a struct. :-)
A majority of peer review feedback didn't see the need for variant storage. Eliminating it very significantly reduces the complexity of the implementation, it's a big gain. I was able to SFINAE all the constructors because of the compile time budget released by eliminating the variant storage. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
On 12/07/2017 02:18, Niall Douglas wrote:
On 11/07/2017 12:53, Peter Dimov wrote:
I would make outcome<> reuse 100% of result<>'s implementation, by stealing another page from your playbook:
class extended_error_code { std::error_code e_; std::exception_ptr x_; };
template<class T> using outcome = result<T, extended_error_code>;
That may well happen yet. What held me back was that the universality of EC = error_code is very important in order to use TRY effectively. That's what led to the split design you see today, so you're basically exchanging some purity in the design for ease of programming. TRY is such a boon for not typing boilerplate.
Perhaps: struct extended_error_code : public std::error_code { std::exception_ptr ex; }; template<class T> using outcome = result<T, extended_error_code>; This allows generic code to treat EC exactly as a std::error_code (both for method calls and to slice off the exception if they wish). Having said that, this would basically render it impossible to have value + exception *without* an error_code. You could mitigate that by defining a default "there is an exception" error_code (which you might be doing anyway), though it feels a little weird. (Then again, it's probably worse to leave the std::error_code default-constructed.)
A majority of peer review feedback didn't see the need for variant storage. Eliminating it very significantly reduces the complexity of the implementation, it's a big gain. I was able to SFINAE all the constructors because of the compile time budget released by eliminating the variant storage.
If you're going to maintain strict no-value-plus-error semantics then union/variant storage makes sense, as otherwise you're wasting memory. I'm not sure why this would increase complexity.
On 12/07/2017 11:52, Peter Dimov wrote:
Having said that, this would basically render it impossible to have value + exception *without* an error_code.
Why would one ever want that?
People using expected<T, exception_ptr>, for one. Perhaps those people are out of scope for Outcome, though. But as long as those people are allowed to pretend that error_codes don't exist (ie. it picks an appropriate non-default error code for any exception) then they probably won't care.
Mere moments ago, quoth I:
If you're going to maintain strict no-value-plus-error semantics then union/variant storage makes sense, as otherwise you're wasting memory. I'm not sure why this would increase complexity.
Although of course unions can be problematic for T with non-trivial copy constructors (and for exception_ptr, which also has a non-trivial copy constructor). A proper variant implementation should take care of that for you, though this didn't help you in Outcome v1 since you were rolling your own variant implementation. Perhaps this is what you were referring to? If you're using struct { T; EC } storage, what do you do with non-default-constructible T when constructed with an error code only? Leaving it unconstructed seems like the only reasonable solution, but this then either requires mucking about with constructors and destructors in annoying fashions or using std::aligned_storage rather than embedding T directly (which still requires mucking about with constructors and destructors). Using a variant just seems like the simpler way to go for this case.
A majority of peer review feedback didn't see the need for variant storage. Eliminating it very significantly reduces the complexity of the implementation, it's a big gain. I was able to SFINAE all the constructors because of the compile time budget released by eliminating the variant storage.
If you're going to maintain strict no-value-plus-error semantics then union/variant storage makes sense, as otherwise you're wasting memory. I'm not sure why this would increase complexity.
I did some benchmarking before making the change to non-variant storage, and found a worst case performance loss of 3-6% depending on compiler. And by worst case, I mean where we do nothing other than return outcomes, and it's 3 CPU cycle hit over ten outcomes returned. I think we'll live. I also did some benchmarking of a std::variant based toy outcome v2 and found compile times to be unacceptably high. The present v2 outcome requires about 4 seconds minimum per compiland, most of which stems from <type_traits> which is unavoidable. std::variant was adding 2 seconds to that, so up to a 50% compile time increase just for naive usage. Just because we don't store strict value-or-error doesn't mean we can't pretend we do in the API. And it eliminates so much special casing for achieving never-empty guarantees etc, it's a lot less work for the compiler and me the developer. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
On Thu, Jul 13, 2017 at 3:12 AM, Niall Douglas via Boost < boost@lists.boost.org> wrote:
A majority of peer review feedback didn't see the need for variant storage. Eliminating it very significantly reduces the complexity of the implementation, it's a big gain. I was able to SFINAE all the constructors because of the compile time budget released by eliminating the variant storage.
If you're going to maintain strict no-value-plus-error semantics then union/variant storage makes sense, as otherwise you're wasting memory. I'm not sure why this would increase complexity.
I did some benchmarking before making the change to non-variant storage, and found a worst case performance loss of 3-6% depending on compiler.
Would you be willing to share some of these benchmarks? I've never benchmarked Noexcept, it would be interesting to see how it compares.
A majority of peer review feedback didn't see the need for variant storage. Eliminating it very significantly reduces the complexity of the implementation, it's a big gain. I was able to SFINAE all the constructors because of the compile time budget released by eliminating the variant storage.
If you're going to maintain strict no-value-plus-error semantics then union/variant storage makes sense, as otherwise you're wasting memory. I'm not sure why this would increase complexity.
I did some benchmarking before making the change to non-variant storage, and found a worst case performance loss of 3-6% depending on compiler.
Would you be willing to share some of these benchmarks? I've never benchmarked Noexcept, it would be interesting to see how it compares.
https://github.com/ned14/outcome/tree/master/benchmark It would indeed be very interesting to see how much overhead TLS introduces. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
On Tue, Jul 11, 2017 at 1:08 AM, Niall Douglas via Boost < boost@lists.boost.org> wrote:
outcome<handle, std::error_code, std::filesystem::path>
... could return an open file handle on success, or an error code plus the failing path on failure.
The third parameter, "error info", should not be specified by the error reporting code because what info is relevant to a failure depends on the context, which is not know an the point you report the error.
For example, one could build your Noexcept library with it quite easily, and thus "plug in" to Expected, P0650 etc.
I think Noexcept is a lot more lightweight than you think. The internal machinery it is based on (what I think you imagine your building block would replace) is about 500 lines, out of about 800.
As you saw on SG14, using any black box library routines is always going to be a problem for the fixed latency user base.
What is a black box library routine? If you're referring to the use of TLS, like I said in that thread, it's a constexpr constructor so there is nothing to initialize and no reason for the TLS to be slow. Nobody on SG14 challenged this point, so I'm not sure what you're referring to.
Your library is shorter than mine, but it calls unknown latency routines. Mine never does.
That was addressing your offer to use Outcome as a "building block" for Noexcept. The point is, the "building block" is heavier than the "product". :)
You also impose TLS on your end users. Mine is much lower level than that, if end users wish to combine mine with TLS to achieve your library, they'll find it very easy.
It's the other way around, actually. The use of TLS moves the error objects off the critical path and removes the coupling between errors and error-neutral contexts. These are Good Things. The decision to force users to enumerate their error types (recall again exception specifications) and to move errors up the call chain one level at a time should be justified and supported with data showing that thread_local is too costly in practice. And the thing is, there is no reason for it to be costly. If it helps, think of it as the refcounting support shared_ptr requires: we can call it tricky, but it is not a problem. Worst case, Noexcept has to implement it if it turns out that the built-in support on some platform is inefficient.
On 11/07/2017 18:13, Emil Dotchevski wrote:
On Tue, Jul 11, 2017 at 1:08 AM, Niall Douglas via Boost <boost@lists.boost.org <mailto:boost@lists.boost.org>> wrote:
outcome<handle, std::error_code, std::filesystem::path>
... could return an open file handle on success, or an error code plus the failing path on failure.
The third parameter, "error info", should not be specified by the error reporting code because what info is relevant to a failure depends on the context, which is not know an the point you report the error.
That *may* be the case, but it is not always the case. In the case of say a file rename operation, it's very reasonable to supply error context info of the two paths involved. Like std::filesystem_error does. For such a rename() function, sure you'd hard code the error info type.
As you saw on SG14, using any black box library routines is always going to be a problem for the fixed latency user base.
What is a black box library routine? If you're referring to the use of TLS, like I said in that thread, it's a constexpr constructor so there is nothing to initialize and no reason for the TLS to be slow. Nobody on SG14 challenged this point, so I'm not sure what you're referring to.
I think that nobody *bothered* to challenge you. That's very different. They indicated misgivings with that design choice, you did not acknowledge them in a way they felt indicated you were open to being corrected, so they said nothing. Happens all the time on boost-dev too of course. Personally speaking, I actually don't know in truth. I just feel deep suspicion. TLS used to be awful unpredictable latency some years ago, only Windows's TlsAlloc() was sane, and it only had 64 slots for the entire process which was easy to exceed. But C++11's thread_local has forced significant improvements. I know what those are in theory, but I've done no deep dive into individual, specific implementations. I'm pretty sure most, if not almost all, on SG14 are in the same boat. C++ 11 thread_local implementations are too new yet. A really great CppCon talk topic would be benchmarking and poking with a stick the three main thread_local implementations. Easily a full hour.
Your library is shorter than mine, but it calls unknown latency routines. Mine never does.
That was addressing your offer to use Outcome as a "building block" for Noexcept. The point is, the "building block" is heavier than the "product". :)
More lines of code has little to do with heaviness. I got some flak off Reddit regarding Outcome v1's length in line count. Totally irrelevant to compile time load.
You also impose TLS on your end users. Mine is much lower level than that, if end users wish to combine mine with TLS to achieve your library, they'll find it very easy.
It's the other way around, actually. The use of TLS moves the error objects off the critical path and removes the coupling between errors and error-neutral contexts. These are Good Things.
The decision to force users to enumerate their error types (recall again exception specifications) and to move errors up the call chain one level at a time should be justified and supported with data showing that thread_local is too costly in practice.
You're forgetting one of the primary reasons to use an Outcome/Expected type is deliberately encode failure handling near the point of failure. People specifically want to see the handling code there so it can be audited and writing it cannot be moved elsewhere. So you want those error types in there to force the issue.
And the thing is, there is no reason for it to be costly. If it helps, think of it as the refcounting support shared_ptr requires: we can call it tricky, but it is not a problem. Worst case, Noexcept has to implement it if it turns out that the built-in support on some platform is inefficient.
I remain unconvinced. I'm still strongly of the opinion that if you want C++ exception like semantics, turn on C++ exceptions support. The primary reason to use Expected/Outcome/whatever is where it's better in every way to use those semantics instead for some particular use case. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
On Tue, Jul 11, 2017 at 12:43 PM, Niall Douglas via Boost < boost@lists.boost.org> wrote:
On Tue, Jul 11, 2017 at 1:08 AM, Niall Douglas via Boost <boost@lists.boost.org <mailto:boost@lists.boost.org>> wrote:
outcome<handle, std::error_code, std::filesystem::path>
... could return an open file handle on success, or an error code
On 11/07/2017 18:13, Emil Dotchevski wrote: plus
the failing path on failure.
The third parameter, "error info", should not be specified by the error reporting code because what info is relevant to a failure depends on the context, which is not know an the point you report the error.
That *may* be the case, but it is not always the case.
When is it not the case? A trivial program that doesn't need error handling library. Otherwise, the low level library that reports the error can not know what is _needed_ in that program to handle the error. At the point of reporting, all you can do is get things going, but most of the relevant context comes in higher level functions. And, importantly, the data that comes from the context in which the failure is reported does _not_ depend on the failure. So, it is critical to allow such data to be associated with _any_ error.
In the case of say a file rename operation, it's very reasonable to supply error context info of the two paths involved. Like std::filesystem_error does. For such a rename() function, sure you'd hard code the error info type.
As you saw on SG14, using any black box library routines is always
going
to be a problem for the fixed latency user base.
What is a black box library routine? If you're referring to the use of TLS, like I said in that thread, it's a constexpr constructor so there is nothing to initialize and no reason for the TLS to be slow. Nobody on SG14 challenged this point, so I'm not sure what you're referring to.
I think that nobody *bothered* to challenge you. That's very different. They indicated misgivings with that design choice, you did not acknowledge them in a way they felt indicated you were open to being corrected, so they said nothing. Happens all the time on boost-dev too of course.
I think they, like you, can't point at a particular problem but generally distrust it and so they remain silent. Regardless, most of the arguments I'm making are about semantics, not speed. In Noexcept TLS use is means to an end, that end being moving the error object out of the critical path, because the error is almost exclusively of concern only to the code that reports it and the code that handles it.
Personally speaking, I actually don't know in truth. I just feel deep suspicion. TLS used to be awful unpredictable latency some years ago, only Windows's TlsAlloc() was sane, and it only had 64 slots for the entire process which was easy to exceed. But C++11's thread_local has forced significant improvements. I know what those are in theory, but I've done no deep dive into individual, specific implementations. I'm pretty sure most, if not almost all, on SG14 are in the same boat. C++ 11 thread_local implementations are too new yet.
A really great CppCon talk topic would be benchmarking and poking with a stick the three main thread_local implementations. Easily a full hour.
Yes, however consider that the general problem of implementing TLS that requires dynamic initialization and whatnot is a lot more complex than what Noexcept needs. Literally, to make Noexcept work, you need a piece of TLS memory where one pointer is set to zero. This is not a tall order, though I admit that a general solution might do it poorly.
Your library is shorter than mine, but it calls unknown latency routines. Mine never does.
That was addressing your offer to use Outcome as a "building block" for Noexcept. The point is, the "building block" is heavier than the "product". :)
More lines of code has little to do with heaviness. I got some flak off Reddit regarding Outcome v1's length in line count. Totally irrelevant to compile time load.
Agreed. I still don't think it's serious to suggest that it makes sense to implement Noexcept in terms of Outcome. :)
You also impose TLS on your end users. Mine is much lower level than that, if end users wish to combine mine with TLS to achieve your library, they'll find it very easy.
It's the other way around, actually. The use of TLS moves the error objects off the critical path and removes the coupling between errors and error-neutral contexts. These are Good Things.
The decision to force users to enumerate their error types (recall again exception specifications) and to move errors up the call chain one level at a time should be justified and supported with data showing that thread_local is too costly in practice.
You're forgetting one of the primary reasons to use an Outcome/Expected type is deliberately encode failure handling near the point of failure. People specifically want to see the handling code there so it can be audited and writing it cannot be moved elsewhere. So you want those error types in there to force the issue.
This use case is supported by TLS storage as well, however in my experience the essence of this use case is that the program detects the error, logs it and continues, there is really no recovery or handling. This is legit, but in this case you need a good logging library more than you need a good error handling library (the only other variation of "I'm dealing with the error right now" is to translate it to another error, which is always a bad idea.)
And the thing is, there is no reason for it to be costly. If it helps, think of it as the refcounting support shared_ptr requires: we can call it tricky, but it is not a problem. Worst case, Noexcept has to implement it if it turns out that the built-in support on some platform is inefficient.
I remain unconvinced.
I'm still strongly of the opinion that if you want C++ exception like semantics, turn on C++ exceptions support.
I agree. Noexcept is needed when you can't do that for some domain-specific reasons or because the code you're dealing with is not exception-safe (I have seen a lot of hand-waving that domain-specific reasons exist in practice, but I have never seen hard data to back that up; and dealing with code that is not exception-safe is pretty common.) Anyway, what you call exception-like semantics in this case is the ability to efficiently transport arbitrary types. The reason that is important is because otherwise you need to translate (bad) or use exception_ptr. The problem with using exception_ptr is that it does require an allocation, and there is no way to interrogate it about its content. From where I stand, Outcome does not solve the most important problem that needs solving by an error handling library.
Outcome does not solve the most important problem that needs solving by an error handling library.
Does Expected? Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
On Tue, Jul 11, 2017 at 2:11 PM, Niall Douglas via Boost < boost@lists.boost.org> wrote:
Outcome does not solve the most important problem that needs solving by an error handling library.
Does Expected?
Nope, but the original outcome<T> was closer. I thought, perhaps it is possible to make it able to transport arbitrary error types, and not by exception_ptr. My attempt at solving that problem lead me to TLS but maybe there are other ways. On the other hand, I don't see a problem with TLS, it seems the perfect solution. And I don't necessarily mean this from performance point of view, it's really a philosophical disagreement. The error object is a communication channel between the error-detecting code and the error-handling code; everyone else should keep quiet except maybe to add relevant contextual data. If you would accept this analogy, if I send you a package, it seems wrong for the postal service to open it up and replace the contents with something they think is better, but I'm fine with them slapping a label or two on the outside of the box. :)
On Tue, Jul 11, 2017 at 3:16 PM, Emil Dotchevski <emildotchevski@gmail.com> wrote:
On Tue, Jul 11, 2017 at 2:11 PM, Niall Douglas via Boost < boost@lists.boost.org> wrote:
Outcome does not solve the most important problem that needs solving by an error handling library.
Does Expected?
Nope, but the original outcome<T> was closer. I thought, perhaps it is possible to make it able to transport arbitrary error types, and not by exception_ptr. My attempt at solving that problem lead me to TLS but maybe there are other ways.
Allow me to clarify. Suppose I have a function foo which returns FILE * on success, some EC1 on failure, and another function bar(), which calls foo and returns an int on success, some EC2 on failure. I believe in terms of Outcome this would be: outcome::result<FILE *,EC1> foo() noexcept; outcome::result<int,EC2> bar() noexcept { if( auto r=foo() ) { //no error, use r.value(), produce the int result or return EC2(x). } else { return ______; } } What do you recommend in place of _____? Here is the same code in terms of Noexcept: FILE * foo() noexcept; int bar() noexcept { if( FILE * r=foo() ) { //no error, use r, produce the int result or return throw_(EC2(x)). } else { return throw_(); } } That is, with Noexcept, bar() would not care what error types propagate out of foo because it can't handle any errors anyway. Whatever the error is, it is simply passed to the caller. Requiring functions to always know what error types they may return is reinventing exception specifications. Let's not resurrect that monster.
2017-07-12 19:11 GMT+02:00 Emil Dotchevski via Boost <boost@lists.boost.org> :
On Tue, Jul 11, 2017 at 3:16 PM, Emil Dotchevski <emildotchevski@gmail.com
wrote:
On Tue, Jul 11, 2017 at 2:11 PM, Niall Douglas via Boost < boost@lists.boost.org> wrote:
Outcome does not solve the most important problem that needs solving by an error handling library.
Does Expected?
Nope, but the original outcome<T> was closer. I thought, perhaps it is possible to make it able to transport arbitrary error types, and not by exception_ptr. My attempt at solving that problem lead me to TLS but maybe there are other ways.
Allow me to clarify. Suppose I have a function foo which returns FILE * on success, some EC1 on failure, and another function bar(), which calls foo and returns an int on success, some EC2 on failure. I believe in terms of Outcome this would be:
outcome::result<FILE *,EC1> foo() noexcept;
outcome::result<int,EC2> bar() noexcept { if( auto r=foo() ) { //no error, use r.value(), produce the int result or return EC2(x). } else { return ______; } }
What do you recommend in place of _____?
Here is the same code in terms of Noexcept:
FILE * foo() noexcept;
int bar() noexcept { if( FILE * r=foo() ) { //no error, use r, produce the int result or return throw_(EC2(x)). } else { return throw_(); } }
That is, with Noexcept, bar() would not care what error types propagate out of foo because it can't handle any errors anyway. Whatever the error is, it is simply passed to the caller.
The default EC type in outcome::result<> is std::error_code, and it is possible to use only this type throughout entire program (similarly to std::unique_ptr<T>: you can use it all around the program and not even be aware that it had a second template parameter). With std::error_code you do acheive this guarantee that the original error inofrmation is always preserved as the control goes throughout the layers of the program. Of course, you cannot carry arbitrary payload now, but given that these errors are to be handled immediatly in the next layer, it should not be that much of the problem. Regards, &rzej;
On Wed, Jul 12, 2017 at 10:23 AM, Andrzej Krzemienski via Boost < boost@lists.boost.org> wrote:
On Tue, Jul 11, 2017 at 3:16 PM, Emil Dotchevski < emildotchevski@gmail.com
wrote:
On Tue, Jul 11, 2017 at 2:11 PM, Niall Douglas via Boost < boost@lists.boost.org> wrote:
Outcome does not solve the most important problem that needs solving by an error handling library.
Does Expected?
Nope, but the original outcome<T> was closer. I thought, perhaps it is possible to make it able to transport arbitrary error types, and not by exception_ptr. My attempt at solving that problem lead me to TLS but maybe there are other ways.
Allow me to clarify. Suppose I have a function foo which returns FILE * on success, some EC1 on failure, and another function bar(), which calls foo and returns an int on success, some EC2 on failure. I believe in terms of Outcome this would be:
outcome::result<FILE *,EC1> foo() noexcept;
outcome::result<int,EC2> bar() noexcept { if( auto r=foo() ) { //no error, use r.value(), produce the int result or return EC2(x). } else { return ______; } }
What do you recommend in place of _____?
Here is the same code in terms of Noexcept:
FILE * foo() noexcept;
int bar() noexcept { if( FILE * r=foo() ) { //no error, use r, produce the int result or return throw_(EC2(x)). } else { return throw_(); } }
That is, with Noexcept, bar() would not care what error types propagate out of foo because it can't handle any errors anyway. Whatever the error is, it is simply passed to the caller.
The default EC type in outcome::result<> is std::error_code, and it is possible to use only this type throughout entire program
I didn't mean that you would design the program like this, the point is that you may not have control over the fact that foo returns EC1, and you still have to be able to write bar() (I should have made that clearer by using different namespaces.) In this comment you're echoing what Niall was saying in the documentation of the original Outcome, where he had several paragraphs attempting to convince the reader to stop using random error codes and _always_ use std::error_code, with technical phrases like "don't be anti-social" :) But that is not our reality, and it will never be our reality in C++ because C++ programs do use C libraries, and because different C++ libraries commonly use their own types for similar things. This is especially true for error codes.
given that these errors are to be handled immediatly in the next layer, it should not be that much of the problem.
In my example the error is not to be handled immediately in the next layer. I don't need an error handling library if the error is always handled "in the next layer".
On Wed, Jul 12, 2017 at 11:49 AM, Emil Dotchevski <emildotchevski@gmail.com> wrote:
On Wed, Jul 12, 2017 at 10:23 AM, Andrzej Krzemienski via Boost < boost@lists.boost.org> wrote:
On Tue, Jul 11, 2017 at 3:16 PM, Emil Dotchevski < emildotchevski@gmail.com
wrote:
On Tue, Jul 11, 2017 at 2:11 PM, Niall Douglas via Boost < boost@lists.boost.org> wrote:
Outcome does not solve the most important problem that needs solving by an error handling library.
Does Expected?
Nope, but the original outcome<T> was closer. I thought, perhaps it is possible to make it able to transport arbitrary error types, and not by exception_ptr. My attempt at solving that problem lead me to TLS but maybe there are other ways.
Allow me to clarify. Suppose I have a function foo which returns FILE * on success, some EC1 on failure, and another function bar(), which calls foo and returns an int on success, some EC2 on failure. I believe in terms of Outcome this would be:
outcome::result<FILE *,EC1> foo() noexcept;
outcome::result<int,EC2> bar() noexcept { if( auto r=foo() ) { //no error, use r.value(), produce the int result or return EC2(x). } else { return ______; } }
What do you recommend in place of _____?
Here is the same code in terms of Noexcept:
FILE * foo() noexcept;
int bar() noexcept { if( FILE * r=foo() ) { //no error, use r, produce the int result or return throw_(EC2(x)). } else { return throw_(); } }
That is, with Noexcept, bar() would not care what error types propagate out of foo because it can't handle any errors anyway. Whatever the error is, it is simply passed to the caller.
The default EC type in outcome::result<> is std::error_code, and it is possible to use only this type throughout entire program
I didn't mean that you would design the program like this, the point is that you may not have control over the fact that foo returns EC1, and you still have to be able to write bar() (I should have made that clearer by using different namespaces.)
In this comment you're echoing what Niall was saying in the documentation of the original Outcome, where he had several paragraphs attempting to convince the reader to stop using random error codes and _always_ use std::error_code, with technical phrases like "don't be anti-social" :)
But that is not our reality, and it will never be our reality in C++ because C++ programs do use C libraries, and because different C++ libraries commonly use their own types for similar things. This is especially true for error codes.
given that these errors are to be handled immediatly in the next layer, it should not be that much of the problem.
In my example the error is not to be handled immediately in the next layer. I don't need an error handling library if the error is always handled "in the next layer".
To clarify the clarification of the clarification, I _am_ interested in finding a way to express the equivalent of the Noexcept return throw_() without using TLS, and I don't insist on it being a free function; for example it would be sufficient if somehow I could just return r in case of an error, as long as it works regardless of what error type r might contain, and of course it should be reasonably efficient.
Emil Dotchevski via Boost Sent: Donnerstag, 13. Juli 2017 00:27
To clarify the clarification of the clarification, I _am_ interested in finding a way to express the equivalent of the Noexcept return throw_() without using TLS, and I don't insist on it being a free function; for example it would be sufficient if somehow I could just return r in case of an error, as long as it works regardless of what error type r might contain, and of course it should be reasonably efficient.
Have you thought about using a type-erased factory - like function<exception_ptr()> - as the error type? Assuming that a) the function class implementation is small-object-optimized and b) that small-object buffer is large enough and c) the actual function object is very cheap to construct/copy/destruct... I think the speed could be acceptable. Still slower than copying some 2-3 ints, but probably faster than exception_ptr. This is purely a (somewhat) educated guess though, I haven't run any benchmarks. Regards, Paul
On Thu, Jul 13, 2017 at 12:55 AM, Groke, Paul via Boost < boost@lists.boost.org> wrote:
Emil Dotchevski via Boost Sent: Donnerstag, 13. Juli 2017 00:27
To clarify the clarification of the clarification, I _am_ interested in finding a way to express the equivalent of the Noexcept return throw_() without using TLS, and I don't insist on it being a free function; for example it would be sufficient if somehow I could just return r in case of an error, as long as it works regardless of what error type r might contain, and of course it should be reasonably efficient.
Have you thought about using a type-erased factory - like function<exception_ptr()> - as the error type?
exception_ptr needs a memory allocation so that's a no-go.
From: Emil Dotchevski via Boost Sent: Donnerstag, 13. Juli 2017 20:12
Have you thought about using a type-erased factory - like function<exception_ptr()> - as the error type?
exception_ptr needs a memory allocation so that's a no-go.
Yes, exception_ptr needs a memory allocation. And atomic ref counting. Which is why I wrote factory function. The idea is that most of the time, you don't want/need to inspect the error, you just have to know that it happened and maybe be able to pass it on. Which can be very efficient if you return a factory. I understand that this is far from perfect, but it's the best idea I have for a single type that can transport arbitrary error information. (An alternative would be a functor that throws the exception when called, but AFAIK that will be even slower - much slower.)
On Fri, Jul 14, 2017 at 12:27 AM, Groke, Paul via Boost < boost@lists.boost.org> wrote:
From: Emil Dotchevski via Boost Sent: Donnerstag, 13. Juli 2017 20:12
Have you thought about using a type-erased factory - like function<exception_ptr()> - as the error type?
exception_ptr needs a memory allocation so that's a no-go.
Yes, exception_ptr needs a memory allocation. And atomic ref counting. Which is why I wrote factory function. The idea is that most of the time, you don't want/need to inspect the error, you just have to know that it happened and maybe be able to pass it on. Which can be very efficient if you return a factory.
I understand that this is far from perfect, but it's the best idea I have for a single type that can transport arbitrary error information. (An alternative would be a functor that throws the exception when called, but AFAIK that will be even slower - much slower.)
Ah, now I get it, thanks for the explanation. There *might* even be a way to get this to work even without memory allocation in the end (without exception_ptr), but I think this is perhaps missing the point of returning an error object, which is to be able to interact with it. Also, reasonably if you could fit the things you need to create the object into a "small object optimized" buffer, you can probably fit the object itself into the same buffer. Noexcept already has that, it's the result<T> object, however it might be too heavy to return up the call chain one level at a time (it is instead designed for capturing the TLS-stored object to postpone its handling, perhaps after moving it to another thread).
2017-07-12 20:49 GMT+02:00 Emil Dotchevski via Boost <boost@lists.boost.org> :
On Wed, Jul 12, 2017 at 10:23 AM, Andrzej Krzemienski via Boost < boost@lists.boost.org> wrote:
On Tue, Jul 11, 2017 at 3:16 PM, Emil Dotchevski < emildotchevski@gmail.com
wrote:
On Tue, Jul 11, 2017 at 2:11 PM, Niall Douglas via Boost < boost@lists.boost.org> wrote:
Outcome does not solve the most important problem that needs solving by an error handling library.
Does Expected?
Nope, but the original outcome<T> was closer. I thought, perhaps it is possible to make it able to transport arbitrary error types, and not by exception_ptr. My attempt at solving that problem lead me to TLS but maybe there are other ways.
Allow me to clarify. Suppose I have a function foo which returns FILE * on success, some EC1 on failure, and another function bar(), which calls foo and returns an int on success, some EC2 on failure. I believe in terms of Outcome this would be:
outcome::result<FILE *,EC1> foo() noexcept;
outcome::result<int,EC2> bar() noexcept { if( auto r=foo() ) { //no error, use r.value(), produce the int result or return EC2(x). } else { return ______; } }
What do you recommend in place of _____?
Here is the same code in terms of Noexcept:
FILE * foo() noexcept;
int bar() noexcept { if( FILE * r=foo() ) { //no error, use r, produce the int result or return throw_(EC2(x)). } else { return throw_(); } }
That is, with Noexcept, bar() would not care what error types propagate out of foo because it can't handle any errors anyway. Whatever the error is, it is simply passed to the caller.
The default EC type in outcome::result<> is std::error_code, and it is possible to use only this type throughout entire program
I didn't mean that you would design the program like this, the point is that you may not have control over the fact that foo returns EC1, and you still have to be able to write bar() (I should have made that clearer by using different namespaces.)
So, you are saying that one can construct a programming problem that Outcome library will not be able to solve. I agree. If you are forced to return EC1 and are forced to use something that returns EC2, where EC1 is not related to EC2, you will probably not be able to solve it decently.
In this comment you're echoing what Niall was saying in the documentation of the original Outcome, where he had several paragraphs attempting to convince the reader to stop using random error codes and _always_ use std::error_code, with technical phrases like "don't be anti-social" :)
Yes. It is my understanding that the value of this library can be only appreciated and exploited when you decide you will be using std::error_code as EC uniformly (or otherwise apply other precautions). One can compare it to the expectation that, C++ exception handling mechanism is useful provided that you decide to throw objects that inherit directly or not from `std::exception`. People generally don't have problem with this constraint. And occasionally some clever people find reasons to throw other types, like `boost::interrupted`.
But that is not our reality, and it will never be our reality in C++ because C++ programs do use C libraries,
I am not sure what using C libraries changes here?
and because different C++ libraries commonly use their own types for similar things. This is especially true for error codes.
I think this is what std::error_code was design for: to convey the original (unconverted) numeric value of any error code (along with the error domain) from any library in a uniform way. The fact that result<T, EC> allows you to put just any EC should not be understood that it is reasonable to return different EC1 and EC2 wherever you like. I would intuitively expect of the users of `result<>` that they use different EC's only in the following situations: 1. EC1 is std::error_code and EC2 is an opaque typedef on std::error_code, and I need an opaque typedef to customize the behavior of `result` on it. 2. The usage of a custom EC2 is completely encapsulated from the outside world: I use it in one translation unit internally, and never expose it in the interface, as shown in my example with the parser: https://github.com/akrzemi1/__sandbox__/blob/master/outcome_practical_exampl...
given that these errors are to be handled immediatly in the next layer, it should not be that much of the problem.
In my example the error is not to be handled immediately in the next layer. I don't need an error handling library if the error is always handled "in the next layer".
If by "error handling" you mean "never be forced to respond to it in the next layer" (note: not "handle" but "respond"), you may say that Outcome is not a library for error handling. But you may still find it useful for situations that are not "errors" by your definition, but that occur in programs, and are "irregular" in some sense, and you need to respond to them in the next layer. To "respond" is different than to "handle", because the "response" is usually to report it one level up, so that it still needs to be responded to. It is tat this decision to forward the condition up is noted explicitly in the code. Sometimes you do not want this explicitness and you will use stack unwinding. Sometimes you want this explicitness and this is where Outcome is helpful. Regards, &rzej;
On Thu, Jul 13, 2017 at 2:16 AM, Andrzej Krzemienski via Boost < boost@lists.boost.org> wrote:
2017-07-12 20:49 GMT+02:00 Emil Dotchevski via Boost < boost@lists.boost.org> :
On Wed, Jul 12, 2017 at 10:23 AM, Andrzej Krzemienski via Boost < boost@lists.boost.org> wrote:
On Tue, Jul 11, 2017 at 3:16 PM, Emil Dotchevski < emildotchevski@gmail.com
wrote:
On Tue, Jul 11, 2017 at 2:11 PM, Niall Douglas via Boost < boost@lists.boost.org> wrote:
> Outcome does not solve the most important problem that needs solving by an > error handling library.
Does Expected?
Nope, but the original outcome<T> was closer. I thought, perhaps it is possible to make it able to transport arbitrary error types, and not by exception_ptr. My attempt at solving that problem lead me to TLS but maybe there are other ways.
Allow me to clarify. Suppose I have a function foo which returns FILE * on success, some EC1 on failure, and another function bar(), which calls foo and returns an int on success, some EC2 on failure. I believe in terms of Outcome this would be:
outcome::result<FILE *,EC1> foo() noexcept;
outcome::result<int,EC2> bar() noexcept { if( auto r=foo() ) { //no error, use r.value(), produce the int result or return EC2(x). } else { return ______; } }
What do you recommend in place of _____?
Here is the same code in terms of Noexcept:
FILE * foo() noexcept;
int bar() noexcept { if( FILE * r=foo() ) { //no error, use r, produce the int result or return throw_(EC2(x)). } else { return throw_(); } }
That is, with Noexcept, bar() would not care what error types propagate out of foo because it can't handle any errors anyway. Whatever the error is, it is simply passed to the caller.
The default EC type in outcome::result<> is std::error_code, and it is possible to use only this type throughout entire program
I didn't mean that you would design the program like this, the point is that you may not have control over the fact that foo returns EC1, and you still have to be able to write bar() (I should have made that clearer by using different namespaces.)
So, you are saying that one can construct a programming problem that Outcome library will not be able to solve.
No, what I am saying is stronger: 1) the ability to transport arbitrary error types is needed, and this is reflected in the current Outcome design by the addition of the extra template parameters; but 2) this approach suffers from the same problems exception specifications do.
I didn't mean that you would design the program like this, the point is that you may not have control over the fact that foo returns EC1, and you still have to be able to write bar() (I should have made that clearer by using different namespaces.)
In this comment you're echoing what Niall was saying in the documentation of the original Outcome, where he had several paragraphs attempting to convince the reader to stop using random error codes and _always_ use std::error_code, with technical phrases like "don't be anti-social" :)
But that is not our reality, and it will never be our reality in C++ because C++ programs do use C libraries, and because different C++ libraries commonly use their own types for similar things. This is especially true for error codes.
I just don't see this argument. If you're facing multiple third party C libraries each with their own error coding, that's exactly what std::error_code is there to handle non-intrusively. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
On Thu, Jul 13, 2017 at 3:16 AM, Niall Douglas via Boost < boost@lists.boost.org> wrote:
I didn't mean that you would design the program like this, the point is that you may not have control over the fact that foo returns EC1, and you still have to be able to write bar() (I should have made that clearer by using different namespaces.)
In this comment you're echoing what Niall was saying in the documentation of the original Outcome, where he had several paragraphs attempting to convince the reader to stop using random error codes and _always_ use std::error_code, with technical phrases like "don't be anti-social" :)
But that is not our reality, and it will never be our reality in C++ because C++ programs do use C libraries, and because different C++ libraries commonly use their own types for similar things. This is especially true for error codes.
I just don't see this argument.
If you're facing multiple third party C libraries each with their own error coding, that's exactly what std::error_code is there to handle non-intrusively.
If std::error_code is sufficient, put your money where your mouth is and go back to outcome v1 where the only choices were std::error_code and std::exception_ptr. But the reality is that std::error_code is not sufficient (perhaps not due to its own deficiencies); in practice you do need to be able to transport more or less arbitrary error types.
On 14/07/2017 06:09, Emil Dotchevski wrote:
If std::error_code is sufficient, put your money where your mouth is and go back to outcome v1 where the only choices were std::error_code and std::exception_ptr. But the reality is that std::error_code is not sufficient (perhaps not due to its own deficiencies); in practice you do need to be able to transport more or less arbitrary error types.
I think the issue is that while std::error_code is sufficient to convey an error *code*, it is not sufficient to convey an error *context*. Outcome v1 solved this by standardising on a slightly-larger type that conveyed a specific small set of additional data, which was deemed good enough for most uses -- but there's still a bit of sacrifice involved there since it would be too much for some cases and too little for others, combined with the separated storage causing it to sometimes go away unexpectedly. I mentioned in a discussion thread at the time that it might be useful to consider having multiple user-defined derived subtypes of std::error_code (or one standard templated one) to add additional context state, similar to how std::exception is subclassed to add additional state to that. Though this has some downsides as well, mainly requirement to not pass by value (unless you want to slice off the extra data) and possible introduction of memory allocations (eg. if std::string were in the payload), which also discourages pass-by-value. Outcome v2 appears to have chosen a different path, where you mostly still use unadorned std::error_code (although since it's templated it's possible you could still do the above) but you also get an extra arbitrary payload pointer *or* an exception_ptr (where then presumably your extra payload is carried in a particular exception subclass). I'm still a bit on the fence about that latter option; exception_ptrs are a bit of a pain to extract useful information from. Or perhaps I'm just misinterpreting something; the docs are still incomplete after all.
Outcome v2 appears to have chosen a different path, where you mostly still use unadorned std::error_code (although since it's templated it's possible you could still do the above) but you also get an extra arbitrary payload pointer *or* an exception_ptr (where then presumably your extra payload is carried in a particular exception subclass). I'm still a bit on the fence about that latter option; exception_ptrs are a bit of a pain to extract useful information from. Or perhaps I'm just misinterpreting something; the docs are still incomplete after all.
You can hook the conversion from result<T, EC1> to result<T, EC2> or outcome<T, EC1, P> via ADL function injection. So v2 doesn't say anything about what the best way of sending payload with your error_code is. In AFIO v2, which I am converting over to Outcome v2 during the next few weeks, I am intending that the code closest to the syscall returns: `result<T, afio_error_code_ref>` ... where `afio_error_code_ref` is *potential* error_code + context. The idea is that we don't waste time copy constructing the path at fault unless asked for. However, `afio_error_code_ref` is non-copyable and non-moveable to prevent it outliving the object it refers to, so anything consuming a `result<T, afio_error_code_ref>` but returns a `result<T, std::error_code>` will dump the context, if returning an `outcome<T, std::error_code, afio_error_code>` it'll do the copy construction then, if an exception is thrown from it then the exception is constructed with the payload embedded and so on. Outcome v2 says nothing about any of this stuff. Up to the end user to customize. As I've mentioned before, you could use TLS to store the extra context too. Up to the end user. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
On Mon, Jul 17, 2017 at 1:38 AM, Niall Douglas via Boost < boost@lists.boost.org> wrote:
However, `afio_error_code_ref` is non-copyable and non-moveable to prevent it outliving the object it refers to, so anything consuming a `result<T, afio_error_code_ref>` but returns a `result<T, std::error_code>` will dump the context, if returning an `outcome<T, std::error_code, afio_error_code>` it'll do the copy construction then, if an exception is thrown from it then the exception is constructed with the payload embedded and so on.
It's better to use refcounting for the contextual data, like Boost Exception does. This is because the context is independent from the error object itself.
Outcome v2 says nothing about any of this stuff. Up to the end user to customize. As I've mentioned before, you could use TLS to store the extra context too. Up to the end user.
The fact that programmers can use TLS for anything they want is not a feature of Outcome :)
On Sun, Jul 16, 2017 at 7:00 PM, Gavin Lambert via Boost < boost@lists.boost.org> wrote:
On 14/07/2017 06:09, Emil Dotchevski wrote:
If std::error_code is sufficient, put your money where your mouth is and go back to outcome v1 where the only choices were std::error_code and std::exception_ptr. But the reality is that std::error_code is not sufficient (perhaps not due to its own deficiencies); in practice you do need to be able to transport more or less arbitrary error types.
I think the issue is that while std::error_code is sufficient to convey an error *code*, it is not sufficient to convey an error *context*.
You're saying that std::error_code is fully capable of conveying _what_ went wrong. This is true, but is it sufficient for an error handling library to only support std::error_code for this purpose? The answer in v1 was "almost", as it also supported std::exception_ptr. The answer in v2 seems to be "not at all", since it turned both into template parameters. The context part is a separate issue and you're right that it can be provided independently of the error type.
Outcome v1 solved this by standardising on a slightly-larger type that conveyed a specific small set of additional data, which was deemed good enough for most uses -- but there's still a bit of sacrifice involved there since it would be too much for some cases and too little for others, combined with the separated storage causing it to sometimes go away unexpectedly.
Yes, it was a compromise, which is the result of the decision to transport error objects into the return value of functions. This design -- and the compromises that follow from it -- would be more reasonable elsewhere, but in error handling very few functions need to interact with the error object. That is why it makes more sense to push it out of the critical path. I mentioned in a discussion thread at the time that it might be useful to
consider having multiple user-defined derived subtypes of std::error_code (or one standard templated one) to add additional context state, similar to how std::exception is subclassed to add additional state to that. Though this has some downsides as well, mainly requirement to not pass by value (unless you want to slice off the extra data) and possible introduction of memory allocations (eg. if std::string were in the payload), which also discourages pass-by-value.
If you enable subclassing, you're enabling more or less arbitrary types. At that point there is little value in mandating std::error_code as the only acceptable base type, in fact it makes more sense to use std::exception. You're right about memory allocations, but while they are not permissible in some cases in others they can be used, and should be supported.
Outcome v2 appears to have chosen a different path, where you mostly still use unadorned std::error_code (although since it's templated it's possible you could still do the above) but you also get an extra arbitrary payload pointer *or* an exception_ptr (where then presumably your extra payload is carried in a particular exception subclass). I'm still a bit on the fence about that latter option; exception_ptrs are a bit of a pain to extract useful information from.
It is true that std::exception_ptr probably needs facilities to inspect the object it contains.
On 13/07/2017 05:11, Emil Dotchevski wrote:
Allow me to clarify. Suppose I have a function foo which returns FILE * on success, some EC1 on failure, and another function bar(), which calls foo and returns an int on success, some EC2 on failure. I believe in terms of Outcome this would be:
outcome::result<FILE *,EC1> foo() noexcept;
outcome::result<int,EC2> bar() noexcept { if( auto r=foo() ) { //no error, use r.value(), produce the int result or return EC2(x). } else { return ______; } }
What do you recommend in place of _____?
FWIW, I believe the Outcome code would be: outcome::result<int,EC2> bar() noexcept { auto r = foo(); if (r) { //no error, use r.value(), produce the int result or return EC2(x). } else { return make_ec2_from_ec1(r.error()); } } Or if EC2 is the same type as or constructible from EC1: outcome::result<int,EC2> bar() noexcept { OUTCOME_TRY(v, foo()); //no error, use v, produce the int result or return EC2(x). } The general recommendation (as Andrzej has already pointed out) is to use the same error code type so that you don't need to do conversions (which might be lossy), but if you insist on using alternate types then you have no choice but to do an error domain conversion. (Or package it in std::error_code, which lets you use multiple error domains.)
On Wed, Jul 12, 2017 at 4:27 PM, Gavin Lambert via Boost < boost@lists.boost.org> wrote:
On 13/07/2017 05:11, Emil Dotchevski wrote:
Allow me to clarify. Suppose I have a function foo which returns FILE * on success, some EC1 on failure, and another function bar(), which calls foo and returns an int on success, some EC2 on failure. I believe in terms of Outcome this would be:
outcome::result<FILE *,EC1> foo() noexcept;
outcome::result<int,EC2> bar() noexcept { if( auto r=foo() ) { //no error, use r.value(), produce the int result or return EC2(x). } else { return ______; } }
What do you recommend in place of _____?
FWIW, I believe the Outcome code would be:
outcome::result<int,EC2> bar() noexcept { auto r = foo(); if (r) { //no error, use r.value(), produce the int result or return EC2(x). } else { return make_ec2_from_ec1(r.error()); } }
This works great in the case of exception specifications too. Right? :) Essentially, the problem is that any framework that requires enumeration of the possible error types has the same problems as statically enforced exception specifications. Consider that if bar is generic, it has no idea what error types foo() may return.
The general recommendation (as Andrzej has already pointed out) is to use the same error code type so that you don't need to do conversions (which might be lossy), but if you insist on using alternate types
I don't insist on using different error types, the use case is when one _has_ a different error type, which in C++ is common.
then you have no choice but to do an error domain conversion.
In case of Outcome, yes. In case of Noexcept, no, it has been designed to be able to propagate the original error object.
On 13/07/2017 11:48, Emil Dotchevski wrote:
then you have no choice but to do an error domain conversion.
In case of Outcome, yes.
In case of Noexcept, no, it has been designed to be able to propagate the original error object.
That worries me a bit where code is using a generic type such as int for error codes but don't have the same meanings for the values. It would be very easy to accidentally let one slip through without conversion so that it ends up representing the wrong error. Granted, Outcome doesn't help much with that issue either, unless you wrap them in a std::error_code. (For Noexcept, the equivalent would be to always convert to a typed enum at the earliest opportunity and never allow a plain int to propagate.)
On Wed, Jul 12, 2017 at 5:29 PM, Gavin Lambert via Boost < boost@lists.boost.org> wrote:
On 13/07/2017 11:48, Emil Dotchevski wrote:
then you have no choice but to do an error domain conversion.
In case of Outcome, yes.
In case of Noexcept, no, it has been designed to be able to propagate the original error object.
That worries me a bit where code is using a generic type such as int for error codes but don't have the same meanings for the values. It would be very easy to accidentally let one slip through without conversion so that it ends up representing the wrong error.
Agreed. I generally don't recommend returning int error codes with Noexcept, for the same reason it is a bad idea to throw an int. But this is a different issue. The problem when you have to go from result<T,E1> to result<U,E2> is not that you could mess up the translation from E1 to E2 (to your point, yes, you could), but that in general you don't know what E1 is, and so there is no good way to design E2 capable to represent all E1 failures efficiently. And if you had a type that could transport more or less any unknown E2 efficiently, then you'd build an error handling library around that, deleting the E template parameter, and you'd be left with result<T>. That was Noexcept V1, but the fact that my solution to the problem pushed the error object out into TLS left very little value in requiring a special return type result<T>, so I deleted that too.
participants (6)
-
Andrzej Krzemienski -
Emil Dotchevski -
Gavin Lambert -
Groke, Paul -
Niall Douglas -
Peter Dimov