<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Hi Lang,<div class=""><br class=""></div><div class="">I want to ask what I feel is an important high-level question here: how does this approach differ, fundamentally, from exceptions, and why should we go down the route of building our own error handling scheme rather than “just” adopting exceptions?</div><div class=""><br class=""></div><div class="">To answer my own question, my impression is that your proposed scheme is functionally similar to exceptions, with the major deviation of being opt-in rather than opt-out. While opt-in is intellectually appealing at first glance, I’m not convinced that it is actually the best solution to some of the problems at play here. In particular, an opt-in scheme will require threading the error-handling type system through many layers of generic and/or boilerplate code in order to allow various callbacks in target backends to report errors properly.</div><div class=""><br class=""></div><div class="">As a concrete example, every backend under the sun has some degree of implicit contract between the backend and the frontend regarding supported IR constructs. This can be as “simple” as ABI lowering and intrinsic names for a typical CPU target, but can be far more complex for targets with non-traditional execution models. In either case, it seems very desirable for the target in the abstract, and instruction selection in particular, to be able to report violations of this contract via the error reporting mechanism. However, to do some in the context of SelectionDAG or FastISel (and I see no particular reason why GlobalISel will be particularly different) would require threading error checking through vast swaths of code both in the instruction selection infrastructure and in the callbacks for the targets themselves. Moreover, instruction selection tends to be a performance sensitive component of the compiler, which argues in favor of exceptions which are, at least notionally, zero-cost.</div><div class=""><br class=""></div><div class="">I’m not claiming here to have a global optimally solution to the problem, and I emphatically <b class="">do</b> want to see LLVM be better behaved about error handling in general. But it’s not clear to me exactly where the right cost/benefit tradeoff lies in terms of error handling technologies.</div><div class=""><br class=""></div><div class="">—Owen</div><div class=""><br class=""></div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Mar 1, 2016, at 1:15 PM, Lang Hames via llvm-commits <<a href="mailto:llvm-commits@lists.llvm.org" class="">llvm-commits@lists.llvm.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">lhames added a comment.<br class=""><br class="">As described in the original RFC (see "Error handling in LLVM libraries." on the llvm-dev mailing list), this patch adds support for an error-handling system tentatively named TypedError. This scheme can be thought of as a hybrid between error returns an exceptions: Errors in the scheme are explicitly represented as return types in the API (like error codes), but error values are structured, user-defined types, similar to c++ exceptions.<br class=""><br class="">The motivation and details of the scheme can be read in the original RFC, my expectation is that this thread will focus on the implementation details.<br class=""><br class=""><br class="">Repository:<br class=""> rL LLVM<br class=""><br class=""><a href="http://reviews.llvm.org/D17778" class="">http://reviews.llvm.org/D17778</a><br class=""><br class=""><br class=""><br class="">_______________________________________________<br class="">llvm-commits mailing list<br class="">llvm-commits@lists.llvm.org<br class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits<br class=""></div></div></blockquote></div><br class=""></div></body></html>