[llvm-commits] [lld] r160732 - /lld/trunk/lib/ReaderWriter/ELF/ReaderELF.cpp

[Nick Kledzik]

On Jul 27, 2012, at 11:24 AM, Sid Manning wrote:
> On 07/27/12 00:39, Nick Kledzik wrote:
> 
>>>> Also, we want Readers to cleanly return with an error_code if an errors
>>> occur.   This is so that the Readers can be used as a library in some other
>>> program (such as an IDE). The ReaderELF currently calls
>>> llvm::report_fatal_error() which usually terminates the program.
>>>> 
>>> No problem, I follow what ReaderCOFF does and return letting EC be dealt with by the caller.
>> It is sad that this loses the message string about what is wrong with the file.   The error_code style seems to be that you need to make up unique error codes for each printed error string.  At some point we will have a better solution for this and revisit this code.
>> 
> Is it reasonable then to extend object_error to support more granular error conditions?
I think the history of error_code was it is an abstraction layer to hide posix error codes and Windows error codes.  

In general the only time you need to define a unique error code is if the client can programmatically handle that particular error case and recover.   In that respect, for file format parsing, we need just one "malformed_object_file" since there is nothing to be done (programmatically) about it.  

But, for error reporting we really want a verbose string (e.g. "relocation 10 has invalid symbol index").  So, we need a way to capture an enumerable error code value and a dynamically generated string.

-Nick