<div dir="ltr">Yeah, thanks for explaining - does seem like a ErrorOr<unsigned> could be better - and a StringError should make that easy enough to do, I think.<br></div><br><div class="gmail_quote"><div dir="ltr">On Mon, Feb 12, 2018 at 8:06 AM Paul Robinson via Phabricator <<a href="mailto:reviews@reviews.llvm.org">reviews@reviews.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">probinson added a comment.<br>
<br>
In <a href="https://reviews.llvm.org/D43152#1004647" rel="noreferrer" target="_blank">https://reviews.llvm.org/D43152#1004647</a>, @dblaikie wrote:<br>
<br>
> Not sure what you mean by "a non-syscall diagnostic"? (there's StringError if you want to just put a string rather than an error code)<br>
<br>
<br>
I mean, a case where a std::error_code is not what we want.<br>
<br>
> What is it that's undesirable about the error handling you've implemented here? Given that there's a similar error path nearby, that seems like a reasonable (or at least consistent) approach... but I've not looked at this area of the code in detail to see if there's something particularly undesirable about it.<br>
<br>
Overloading two return values to indicate an error, instead of a more explicit indication.  And then relying on callers to remember to check for them, instead of forcing callers to check for them.<br>
<br>
<br>
Repository:<br>
  rL LLVM<br>
<br>
<a href="https://reviews.llvm.org/D43152" rel="noreferrer" target="_blank">https://reviews.llvm.org/D43152</a><br>
<br>
<br>
<br>
</blockquote></div>