[PATCH] D17778: TypedError for recoverable error handling

[Lang Hames via llvm-commits]

Hi Rafael,

For this and for the fact that llvm is used in exception free code
> bases I don't think enabling exceptions in llvm code is a viable
> solution in general.


Agreed.

 I just insist that


> * programs can still just use fatal errors.


Yep. One extra thing that I would like to codify (but haven't added to the
docs in this patch) is that the fatal error mechanism for programs should
call exit, rather than crashing or calling abort. We want program
termination due to recoverable errors to look like ordinary program
termination with an error code, rather than a crash.

* when appropriate, libraries can use lighter error handling options
> like an error node in an AST.


Sure.

* an effort is made to port the codebase to use this when appropriate.
> In particular, pretty much anything returning a plain std::error_code
> or bool+std::string is a good candidate for conversion.


Sounds good to me. Uses of std::error_code will be easy enough to find.
Boolean returns will be a little more difficult, but we might even be able
to write a clang tool to spot them.

Cheers,
Lang.


On Thu, Mar 3, 2016 at 4:03 PM, Rafael Espíndola <rafael.espindola at gmail.com
> wrote:

> > If we turned exceptions on we wouldn't need any API changes, but we would
> > pay the overhead for exceptions and RTTI everywhere in LLVM except where
> we
> > explicitly opt out via noexcept specifiers. To get an upper bound on
> this I
> > did a Release (non-LTO) build of LLVM with and without exceptions+RTTI
> > turned on. I didn't get past looking at the binary size differences:
> clang
> > got >9% bigger. Other tools got between 2% and 25% bigger, with most
> > clustered around a 10-15% increase. Those are some scary size
> regressions.
>
> For this and for the fact that llvm is used in exception free code
> bases I don't think enabling exceptions in llvm code is a viable
> solution in general.
>
> Note that in a case where someone controls both FE and backend, they
> could build llvm with exceptions and have it propagate from the
> backend all the way to the FE. It is just llvm always requiring
> exceptions that I don't think is viable.
>
> Given that we need at least some form of "checked std::error_code", I
> am ok with this solution. I just insist that
>
> * programs can still just use fatal errors.
> * when appropriate, libraries can use lighter error handling options
> like an error node in an AST.
> * an effort is made to port the codebase to use this when appropriate.
> In particular, pretty much anything returning a plain std::error_code
> or bool+std::string is a good candidate for conversion.
>
> Cheers,
> Rafael
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160307/00b8ff1d/attachment.html>