On Tuesday, 6 August 2019 02:53:45 PDT Dmitry wrote:
> First of all, thank you for the response.
>
> You said that you have a function that previously was creating a temporary
> file on disk (and could generate eaccess) but now it creates it in memory
> (and can generate enosys instead).
> Correct me if I am wrong, but, from what I can gather, you do not want to
> have a function creating a temp file on disk, nor in memory.

Yes, I do. I need to have a file descriptor shared between two processes, with
the sharing via fork() or SCM_RIGHTS.

> What you want is a facility
> * for creating a temporary file somewhere (for example, using a hard-coded
> logic: first try in memory, if it fails - on disk, or there might be a
> hint-parameter as to where create it)

I really don't want to create temporary files anymore, since that implies
removing them at some point. So I really need memfds. So I can't do your first
point.

> * that could report an error (for example in the form of expected<fd,
> TError>).
> The latter is the most interesting part. As I described in my post, I would
> go for "nested error structure with increasing degree of details":
> 1st level: I would hazard a guess, for majority of callees
> "failed/succeeded" is enough - we have expected<> for this.
> 2nd level, by looking in the man page of the open() syscall, there is a
> couple of broad groups of errors: AccessFailed, BadArguments, maybe
> something else - this information might be necessary for a finer-grained
> handling.
> 3rd level: precise, primarily debug-only, OS-specific errno code:
> struct TError {
> enum TStatus { BadArg, AccessFailed, ... }
> TStatus Status;
> std:::string Args; // used when Status == BadArg
> int SysErrno;
> }
> As I wrote in my post, you can enhance this approach however you want, for
> example place "sub-errors" in a variant<>.

Sorry, you don't get to change the API. Using the API as-is was the big
problem of your post. If you can change my API to make it better and report a
more structured set of information, then the same can be done too for
exceptions.

Your solution requires that at some point in the call stack, the error
condition be consumed and then either augmented or handled. Nothing in that
requires using return values, global/thread-local values (like errno) or
exceptions. All three are possible.

What you're arguing for is sanely designed API and handling error conditions
as close to the error locus as possible. I don't dispute that: that's the
proper and only way to handle errors. What I will agree with you is that using
exceptions makes it to easy *not* to do it, since you can simply "forget" to
handle, then let the error pass on to your caller. When using return values,
the error condition will often be "in your face" and you'll have a hard time
ignoring it.

But C++ does not dictate what you must do. You don't like exceptions? Or don't
feel comfortable writing code with it, like me? Then don't use them. But don't
ask that they be removed from the language. That's not going to happen.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel System Software Products