[llvm-commits] [lld] r160732 - /lld/trunk/lib/ReaderWriter/ELF/ReaderELF.cpp
Nick Kledzik
kledzik at apple.com
Mon Jul 30 13:29:36 PDT 2012
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
More information about the llvm-commits
mailing list