[PATCH] D87987: [llvm-objcopy][NFC] refactor error handling. part 3.

[James Henderson via Phabricator via llvm-commits]

jhenderson added a comment.

In D87987#2299935 <https://reviews.llvm.org/D87987#2299935>, @grimar wrote:

> In D87987#2297596 <https://reviews.llvm.org/D87987#2297596>, @jhenderson wrote:
>
>> Before you go too much further with this, I'd like some comments from others on the approach. The fact that this code is far more extensive and has far more error paths suggests to me that we might be on the wrong approach here, and perhaps we should actually be using the error handler callback approach after all. @grimar/@rupprecht/@MaskRay - any thoughts?
>
> 2. Regarding the error handler callback suggested. I am thinking about something that is implemented in LLD. I.e. a error state is remembered and a error is reported via callback. Then we are trying to stop execution and exit at a convenient place. @jhenderson, did you mean something like this?

I was actually referring more to the style that this patch series initially looked at, which is based on something similar to what I did in the DebugLine parser, which in turn inspired my lightning talk on error handling in libraries three(?) years ago. In other words, the client would provide one or more callbacks for different degrees of severity of problems, which llvm-objcopy's code could then call when an error occurred.

I'm not convinced there are many points in the llvm-objcopy code where continuing after failure makes much sense, personally, so just storing an error state for reporting later seems unnecessary?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D87987/new/

https://reviews.llvm.org/D87987