Re: [boost] [outcome] Second high level summary of review feedback accepted so far

Subject: Re: [boost] [outcome] Second high level summary of review feedback accepted so far
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2017-06-05 11:02:54

> The correct approach here, I think, is not to define fat error codes,
> but to return an outcome whose error() is the error_code and whose
> exception() is the appropriate filesystem_error exception, complete with
> the path(s).
> 
> Setting however both the error_code and the exception_ptr is not
> supported by the current outcome design (and neither would it be
> supported by expected<R, error_code, exception_ptr>.)
> 
> Or, an alternative that scales better would be to take
> 
>    http://pdimov.com/cpp2/P0640R0.pdf
> 
> and store error_code and exception_info, so that later one can use
> 
>    throw_with_info( std::system_error( error() ), info );
> 
> with the additional information (such as paths) being carried by the
> exception_info.

In AFIO v2 I'd personally consider any potential memory allocation in
any of the core API unacceptable (because we never allocate memory in
AFIO v2). Currently we memcpy() the tail of the path into the
error_code_extended on failure, but even that I dislike because each
afio::io_handle already knows its own path, and if it weren't for
lifetime issues I'd just return the pointer to that path and save a lot
of work for everybody.

Down the line AFIO v2 will gain a "fat path" type which is the
combination of an open handle with a path fragment. Those necessarily
will need to decide what to do about lifetime issues. I may yet go light
and make the fat path type just a naked pointer plus filesystem::path,
or I may implement a process-wide registry of "path handles" i.e.
handles opened solely to indicate some unknown location on the
filesystem which is a base for path fragments to work from. I haven't
decided yet, there are a lot of competing tradeoffs, I specifically want
the end user to do all their malloc-work in a pre-init step and away
from any core i/o loops which need to never, ever allocate memory.

Niall

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