<div dir="ltr">Hi Rafael, Peter,<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="font-size:13px">This is a small interface and I think we can do it.</span></blockquote><div><br></div><div>Fair enough. I just tried to implement IndescribableError and realised is fairly problematic in its own way, so in the interests of unblocking things I think we should take your patch and just bail in the conversion method for now. I'll keep thinking about IndescribableError and we can revisit it when I've sorted out the dark corners. Sorry for the hold up!</div><div><br></div><div>I only had two comments on your patch:¬†</div><div><br></div><div>emitError can just be: make_error<StringError>(Message.str()). There's no need for the StringError temporary: make_error forwards arguments to StringError's constructor the same way make_unique does.</div><div><br></div><div>make_error<ECError> should be errorToErrorCode: The latter is the standard term to grep for when looking for the interface between error_code-using API and Error-using API.</div><div><br></div><div>Cheers,</div><div>Lang.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, May 24, 2016 at 6:49 PM, Rafael Esp√≠ndola <span dir="ltr"><<a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 24 May 2016 at 20:34, Lang Hames <<a href="mailto:lhames@gmail.com">lhames@gmail.com</a>> wrote:<br>
> Hi Rafael,<br>
><br>
> Just in case it's useful: You can accumulate Error instances using the<br>
> join_errors function. It's intended for situations where you want to<br>
> accumulate multiple diagnostics before bailing out. That said, I think it<br>
> would be reasonable to just bail early here as you suggested.<br>
<br>
</span>Yes, sorry that is what I meant by "list of error" :-)<br>
<span class=""><br>
> Convertibility to error_code is important: Unless you can be certain that<br>
> all clients of the interface have transitioned 100% to Error, you have to<br>
> assume that a client might call errorToErrorCode, and if you haven't<br>
> implemented the conversion that call will crash.<br>
<br>
</span>This is a small interface and I think we can do it. Even if we want a<br>
fail safe, we should have a single "unhandled_category" with a single<br>
error for the cases where every caller should be using Error.<br>
<span class=""><br>
> I've generally aimed for error_code <-> Error mappings that are reasonably<br>
> information preserving, but we could introduce a new error_category and enum<br>
> in the Error header: IndescribableError, and allow people who are<br>
> introducing new Error types to map to that. It might even serve as a handy<br>
> forcing function to get people to move over.<br>
<br>
</span>Yes, the IndescribableError is what I meant by the unhandled_category.<br>
Having a rich mapping on the other hand makes me very scared of the<br>
prospect of ever finishing the transition. In any case, we should<br>
definitely not adding more error_categories to transition from bool to<br>
Error.<br>
<br>
Cheers,<br>
Rafael<br>
</blockquote></div><br></div>