Add more error checking to llvm-objdump and MachODump

[Pete Cooper via llvm-commits]

> On Dec 14, 2015, at 2:37 PM, Rafael Espíndola <rafael.espindola at gmail.com> wrote:
> 
> On 14 December 2015 at 17:28, Pete Cooper <peter_cooper at apple.com> wrote:
>> Hi Rafael
>> 
>> This is the start of error handling when we encounter errors in __eh_frame parsing.
>> 
>> I add a bool return to printMachOEHFrameSection which returns true if we printed an error.  This is then propagated all the way up the call stack to main().
>> 
>> I think returning a bool makes more sense that report_fatal_error as upon getting an error, we want to continue to dump other sections, and even other eh_frame entries.  I do check this error and ensure we return 1 from main though.
> 
> Please just use fatal errors.
The problem with that is that it gives us no error recovery.  I now get a single error and have to quit via exit(1).

Is that the model we’re planning on using for all of the tools?

Personally I was hoping for something more like clang where if my code contains some errors I can recover and see what comes next.

BTW, i’m not disagreeing with what you say below.  Propagating errors is certainly harder to work with that fatal errors, but I do like the ability to recover.

Cheers,
Pete
> 
> This is program code, not library code. Having an error function that
> prints the message and exits with 1 makes the code far simpler to
> read. In particular it is easy to see that we always exit instead of
> reading potential garbage when forgetting to check the return.
> 
> It is extremely uncommon to see broken .o files. Every single time I
> have seen one is because I broke something in MC. In which case a
> fatal error is also very helpful. It provides a convenient place to
> put a breakpoint and see the entire context (stack) that found the
> problem. With a fancy error handling you have to step down to see what
> decided to return an error.
> 
> Cheers,
> Rafael