[patch] Simplify ErrorOr

Michael Spencer bigcheesegs at gmail.com
Sun Nov 3 19:02:31 PST 2013


On Sat, Nov 2, 2013 at 3:06 PM, Rafael EspĂ­ndola
<rafael.espindola at gmail.com> wrote:
> I noticed that ErrorOr has quiet a bit of complexity and indirection
> to be able to hold a user type.
>
> That feature doesn't seem to be used anymore. This patch removes it,
> it will live in svn history if we ever need it again.

I intend to use it in lld and the Object library to provide more
detailed and actionable info about errors.

>
> If we do need it again, IMHO there are somethings that should be done
> differently
>
> * Holding extra info in the error is not a property a function also
> returning a value or not. The ability to hold extra info should be in
> error_code, so that we don't need the funny looking ErrorOr<void>.

ErrorOr<void> isn't that weird. I just means an error or nothing. We
could also just typedef ErrorOr<void> as Error or something.

As for llvm::error_code, it is explicitly based on the C++11
std::error_code, and I plan to replace it with that when we move over
to C++11.

>
> * The vast majority of use cases don't need it, so it is probably
> better to have a different type that makes it clear user data is being
> hold (say user_error_code<T>). This could then also avoid the separate
> allocation and indirection.

Almost all code would end up using this type then, as it would need to
properly propagate the extra info.

Also, would T be the user data type? That would make it not possible
to propagate different types of user error data.

>
> * The need for anything more than a string is also not clear, so a
> str_error_code would probably be sufficient.

A string is not enough. For example in lld we want to use debug info
to provide better diagnostics. We can't always do this at the time the
error is encountered, so the state needs to be persisted in a easily
usable format.

>
> Cheers,
> Rafael

- Michael Spencer




More information about the llvm-commits mailing list