[PATCH] D17778: TypedError for recoverable error handling

[Owen Anderson via llvm-commits]

> 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.

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