[PATCH] D17778: TypedError for recoverable error handling

[David Blaikie via llvm-commits]

On Tue, Mar 1, 2016 at 1:55 PM, Owen Anderson <resistor at mac.com> wrote:

>
> On Mar 1, 2016, at 1:43 PM, David Blaikie <dblaikie at gmail.com> wrote:
>
> It may be that other approaches, more like the diagnostic handling options
> discussed in the original thread (& that we have plumbed through for the
> "remarks" support). But maybe you need a hard stop on these errors, in
> which case you do need some implicit or explicit control flow to get you
> out. There was a bit of discussion about how to do this for lld recently -
> returning stub results that are "sufficient" maybe with a flag saying "this
> isn't a real result" - more like Clang's Parser/Sema: we don't have error
> results everywhere. We return erroneous stubs and the like which allow a
> lot of Clang to continue on without worrying about whether something
> failed. Only handling the failures in relatively few places.
>
> This is also useful for providing error recovery/multiple errors (eg: this
> instruction /and/ thin instruction were both wrong - so the user doesn't
> have to edit/compile loop again just to find out the two lines they wrote
> both needed changes).
>
>
> I can speak only to my own use case here:  if my frontend provided me with
> contract-violating IR, I want to propagate an error all the way out to the
> the client (non-LLVM code) such that (1) they can log/report the error as
> appropriate for the platform, to aid in future debug, and (2) to give them
> a chance to recover via higher-order mechanisms such as falling back to a
> lower tier JIT, to an interpreter, or simply to an unoptimized
> compilation.  My impression is that #2 tends to get overlooked here, but
> many online and JIT compilation use cases have reasonable fallbacks options
> to continue program execution even if LLVM fails in a nominally
> unrecoverable manner.
>

Fair point - a callback mechanism could still be used to achieve that goal
(or hybrid mechanisms involving the kind of "stub result" sort of stuff
Clang does - you could register a null diagnostic handler and still expect
the system to fail and in (2) I imagine you don't differentiate the
specific failures much just "LLVM JIT didn't work, try the other thing").
Possibly not the best tool for the job, but one path that could be
considered.

But yeah, good to keep that scenario in mind to be sure - thanks for
articulating/clarifying it (& if my responses aren't making sense in that
context, sorry about that - happy to try to clarify/explain differently)

- Dave


>
> —Owen
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160301/36601b89/attachment.html>