<p dir="ltr">I would use it whenever I need to handle runtime error which I can't recover from and I don't have a better way to report the error. I don't agree that it's invisible, the name is pretty explicit in what it does. The specific use case is handling parsing errors in clang-tidy check-specific options. Parsing happens in the check constructor which doesn't have a better way of reporting an error. See <a href="http://reviews.llvm.org/D5602">http://reviews.llvm.org/D5602</a> for the patch where I would use this method instead of ErrorOr<>::operator*.</p>
<div class="gmail_quote">On 9 Oct 2014 22:29, "Reid Kleckner" <<a href="mailto:rnk@google.com">rnk@google.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I don't think we should be burying invisible calls to report_fatal_error in libraries. Can you point at the code which wants to do this?</div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Oct 9, 2014 at 10:30 AM, Alexander Kornienko <span dir="ltr"><<a href="mailto:alexfh@google.com" target="_blank">alexfh@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi rafael,<br>
<br>
This method allows writing code that consistently fails in case of<br>
dereferencing an ErrorOr<> containing no value rather than crashing in debug and<br>
using uninitialized data in release build.<br>
<br>
<a href="http://reviews.llvm.org/D5706" target="_blank">http://reviews.llvm.org/D5706</a><br>
<br>
Files:<br>
  include/llvm/Support/ErrorOr.h<br>
<br>_______________________________________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@cs.uiuc.edu" target="_blank">llvm-commits@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a><br>
<br></blockquote></div><br></div>
</blockquote></div>