Introducing a new error helper, FileError; and upgrading StringError.
FileError
is meant to encapsulate both an Error and a file name/path. It should be used in cases where an Error occurs deep down the call chain, and we want to return it to the caller along with the file name.
Previously, the caller had to know the file name, and in some cases it was unavailable. An example of this could be the loading of a COFF object (OBJ). Those files kinds can contain an indirection to another PDB or OBJ (precompiled headers) file. If that indirection fails to load for some reason, the caller might not have that indirect file name in hand. For those cases, a FileError would be inserted at the right place in the call chain.
Currently FileError logs with the following format: '{file}': {error}, such as: 'test.bin': no such file or directory
StringError
was updated to display the error messages in different ways. These can be:
- display the error_code message, and convert to the same error_code (ECError behavior)
- display an arbitrary string, and convert to a provided error_code (current StringError behavior)
- display both an error_code message and a string, in this order; and convert to the same error_code
These behaviors can be triggered depending on the constructor. The goal is to use StringError as a base class, when a library needs to provide a explicit Error type.
The following illustrates these three cases:
return make_error<CodeViewError>(cv_error_code::corrupt_record); // case 1 return make_error<CodeViewError>(cv_error_code::corrupt_record, "Invalid frame data record format!"); // case 2 return make_error<CodeViewError>("Invalid type index"); // case 3
...CodeViewError being a subtype of StringError only with a minimal implementation:
class CodeViewError : public ErrorInfo<CodeViewError, StringError> { public: using ErrorInfo<CodeViewError, StringError>::ErrorInfo; // inherit constructors CodeViewError(const Twine &S) : ErrorInfo(S, cv_error_code::unspecified) {} static char ID; };
Usages are illustrated in D50664 (pending).
Tested with asserts enabled to ensure all Errors are checked in the unit tests.
I've noticed @lhames mentions here that usage of inconvertibleErrorCode() shall be explicit. I'll change that. Please let me know if there's anything else.