Boost logo

Boost :

Subject: Re: [boost] [outcome] Requesting pre-review of Boost.Outcome tutorial
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2016-11-11 16:37:13


On 11 Nov 2016 at 21:23, Klemens Morgenstern wrote:

> > an explanation and a sort of tutorial explaining the history and
> > purpose of Outcome at https://ned14.github.io/boost.outcome/ and I'd
> > greatly appreciate if people could tell me:
> >
> > 1. Does it make sense?
> Yes, it does. Especially for embedded development, this seems very useful.

Oh great. Thank you. I was worried it was too long and/or boring
and/or confusing.

> Is there a way to switch the behaviour depending on whether exceptions
> are available? I.e. throw if they are, elsewise use the result? Or would
> you consider this a horrible Idea?

Already present. All exceptions are thrown via a user redefinable
macro. Each individual throw gets its own macro. When exceptions are
disabled in the compiler, the default implementation dumps a
stacktrace and terminates the process, but user code can do anything
else it feels like.

I would add that it should be the case that if properly used Outcome
never throws an exception, not ever. Therefore it should never
terminate the process.

One thing I'll add before peer review is an optional facility that it
will cause a link error if your code ever could cause an exception to
throw. This should aid debugging.

> The reason for me would be, that I could write a library which's user
> could use it both ways, depending on what he has available. I think if I
> wanted to provide a way to have a function-call using an exception or an
> error_code, I'd go with the C++11 way, i.e. distinguish this in the
> signature. So for me the main use-case would be, that exceptions might
> not be available.

This is major use case intention for Outcome and exactly what I use
it for myself.

Thanks for the feedback Klemens.

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ 
http://ie.linkedin.com/in/nialldouglas/

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk