<div dir="ltr">Agreed - I'd rather not introduce the complexity of semantically meaningful Error types, if it's reasonable to do so.<br><br>The callback would only be used for recoverable errors, though, yes? Allowing the user to differentiate the two cases ("recoverable things come through the callback, non-recoverable things are errors seen as a result that didn't pass through/come from the callback"). Seems fair to me.</div><br><div class="gmail_quote"><div dir="ltr">On Mon, Mar 19, 2018 at 3:28 PM Rafael Avila de Espindola <<a href="mailto:rafael.espindola@gmail.com">rafael.espindola@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>> writes:<br>
<br>
> *nod* seems pretty reasonable to me - I haven't been looking closely at the<br>
> code so far but just took a bit of a look to try to understand the<br>
> difference between what's there and what you're suggesting, Rafael.<br>
><br>
> If I've got this right - the main thing that'd be simplified by your<br>
> suggested change is to remove the need for the additional complexity of a<br>
> custom Error type while enabling callers that don't care about<br>
> warn-and-continue to stop quickly? (by returning the Error from the handler<br>
> - which isn't provided by the currently proposed patch?)<br>
<br>
Correct. Currently we only have errors, and it is always up to the<br>
caller to decide what to ignore. For example, a file not found error can<br>
be ignored of be the reason for an exit(1) depending on the file and the<br>
program. IMHO the same is true for "unsupported version".<br>
<br>
Having which errors are fatal be a property of the particular error type<br>
is odd.<br>
<br>
Cheers,<br>
Rafael<br>
</blockquote></div>