[PATCH] D44560: [DWARF] Rework debug line parsing to use llvm::Error and callbacks

[David Blaikie via llvm-commits]

Agreed - I'd rather not introduce the complexity of semantically meaningful
Error types, if it's reasonable to do so.

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.

On Mon, Mar 19, 2018 at 3:28 PM Rafael Avila de Espindola <
rafael.espindola at gmail.com> wrote:

> David Blaikie <dblaikie at gmail.com> writes:
>
> > *nod* seems pretty reasonable to me - I haven't been looking closely at
> the
> > code so far but just took a bit of a look to try to understand the
> > difference between what's there and what you're suggesting, Rafael.
> >
> > If I've got this right - the main thing that'd be simplified by your
> > suggested change is to remove the need for the additional complexity of a
> > custom Error type while enabling callers that don't care about
> > warn-and-continue to stop quickly? (by returning the Error from the
> handler
> > - which isn't provided by the currently proposed patch?)
>
> Correct. Currently we only have errors, and it is always up to the
> caller to decide what to ignore. For example, a file not found error can
> be ignored of be the reason for an exit(1) depending on the file and the
> program. IMHO the same is true for "unsupported version".
>
> Having which errors are fatal be a property of the particular error type
> is odd.
>
> Cheers,
> Rafael
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20180319/304a2de6/attachment.html>