<div dir="ltr">Hi there,<br><br>You're right that some of the differences are based on different conditions/needs, and some are based on different styles (some which are historic - some which might vary by individual developer preferences, or common idioms within one part of the codebase that might be different in other parts)<br><br>Probably one of the more generically/full-functioned examples of non-exception error handling would be llvm::Error (& llvm::Expected), like google's util::Status (& util::StatusOr).<br><br>But if there's nothing interesting to say about the failure, a boolean return (or Optional<T> - where T is the success value, and non-present for failure).<br><br>A long time ago some parts of Clang got in the habit of returning 'true' on failure, instead of false - this was in part motivated by the C idiom of non-zero-on-failure/errorcode style failures - but it's gotten all a bit muddled up and I think the general sense is that false on failure is the direction to go moving forward for those sort of situations (where boolean failure is sufficient - no descriptive error message).<br><br>- Dave<br><br><div class="gmail_quote"><div dir="ltr">On Sat, Nov 3, 2018 at 2:08 AM A. Ilchinger via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello,<br>
<br>
as I understand, the LLVM project prohibits the use of exceptions. I<br>
don't want to start a discussion about this decision, but I'd love to<br>
see what alternative error handling is used.<br>
<br>
Could you please point me to some good code examples in the LLVM tree<br>
where one can see how exceptions are avoided? Skimming through the code<br>
I found different approaches (private ctor and create() method with<br>
error return code; using only the ctor and ignoring possible allocation<br>
errors; ...)<br>
Surely, the use of the right error handling strategy is highly<br>
situational, but LLVM also improved over time and without deeper<br>
knowledge of the code base it is impossible for me to see which parts<br>
are "good" and which parts are older and might need refactoring.<br>
<br>
Kind regards<br>
Andreas<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div></div>