[llvm-dev] Examples of exception-free code

[Reid Kleckner via llvm-dev]

Broadly speaking, I would say that LLVM is not a good example for projects
that want to handle errors with reliability. We tend to have two kinds of
errors in compilers:
1. Broken invariants
2. Invalid input

When LLVM detects broken invariants, it tends to assert or exit with a
fatal error. See this long standing guideline:
https://llvm.org/docs/CodingStandards.html#assert-liberally If you are
looking for examples of software that is reliable in the face of unforeseen
faults, LLVM is not a good example of that. As you mention, OOMs are
similarly treated as a fatal error.

You might still be interested in the elaborate infrastructure for handling
relatively common, expected errors of invalid input, missing files, etc. As
David mentioned, there's the llvm::Error and Expected classes.

I'd also point out clang's diagnostic machinery as a common design pattern,
where you record errors on some side context, and then propagate failure
locally with simple boolean return values. This is, IMO, much more
pervasive than Error or error_code, and I personally prefer working with
it. This pattern works well when all errors are generally treated the same
way, using the same recovery strategies, which is usually the case when
attempting to validate input.

On Sat, Nov 3, 2018 at 2:08 AM A. Ilchinger via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> Hello,
>
> as I understand, the LLVM project prohibits the use of exceptions. I
> don't want to start a discussion about this decision, but I'd love to
> see what alternative error handling is used.
>
> Could you please point me to some good code examples in the LLVM tree
> where one can see how exceptions are avoided? Skimming through the code
> I found different approaches (private ctor and create() method with
> error return code; using only the ctor and ignoring possible allocation
> errors; ...)
> Surely, the use of the right error handling strategy is highly
> situational, but LLVM also improved over time and without deeper
> knowledge of the code base it is impossible for me to see which parts
> are "good" and which parts are older and might need refactoring.
>
> Kind regards
> Andreas
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20181105/f3742197/attachment.html>