[PATCH] D19940: Convert PDB error handling into using std::error_code instead of custom error codes

Zachary Turner via llvm-commits llvm-commits at lists.llvm.org
Thu May 5 12:01:00 PDT 2016


zturner added a reviewer: lhames.
zturner updated this revision to Diff 56323.
zturner added a comment.

Convert everything to using llvm::Error.

I chose to do this a little bit different way than what is probably normal.  There are two distinct codepaths.  The DIA codepath and the native PDB parsing codepaths.  I wanted to be able to "namespace" the types of errors that each codepath can produce, so that I could make sure I was not returning a DIA error from the raw codepath, and vice versa.

At the same time, I did not want to make 100 different subclasses of `ErrorInfo`, but I *did* want error messages to be consistent, so that all corrupt file errors have the same error message, etc.

So I chose a hybrid.  I have a `DIAError`, a `RawError`, and a `GenericError`.  Each one defines its own set of error code constants that you can (optionally) use when making the error.  In all cases you also (optionally) pass a context string that gives more detailed information about the site the error occurred at.  This way the class (`DIAError`, `RawError`, etc) provides the high level error message banner, the code provides a consistent general description of the error, and the context provides the detail.

A nice advantage of this is that when converting to a std error_code, you already have an error category defines which translates it into a useful error message.

In the future, I have some more ideas here that will make this even better.  Instead of using an error code, we can define a class for each custom error condition that takes its own set of constructor arguments and has a `format()` method.  This way we could do something like:

  make_error<RawError>(corrupt_file(Path), "No MSF Superblock")

and it could format it as

  Native PDB File Error: The PDB file 'c:\foo.pdb' is corrupt.  Reason: No MSF Superblock'

and this `corrupt_file` class would know how to format the parameters intelligently, instead of just slapping the context onto the end of the string as we currently do.

Adding lang on this review since he wrote the Error stuff, and make he can offer some suggestions about if I'm using this correctly.


http://reviews.llvm.org/D19940

Files:
  include/llvm/DebugInfo/PDB/DIA/DIAError.h
  include/llvm/DebugInfo/PDB/DIA/DIASession.h
  include/llvm/DebugInfo/PDB/DIA/DIASupport.h
  include/llvm/DebugInfo/PDB/GenericError.h
  include/llvm/DebugInfo/PDB/PDB.h
  include/llvm/DebugInfo/PDB/PDBTypes.h
  include/llvm/DebugInfo/PDB/Raw/ByteStream.h
  include/llvm/DebugInfo/PDB/Raw/DbiStream.h
  include/llvm/DebugInfo/PDB/Raw/InfoStream.h
  include/llvm/DebugInfo/PDB/Raw/MappedBlockStream.h
  include/llvm/DebugInfo/PDB/Raw/NameHashTable.h
  include/llvm/DebugInfo/PDB/Raw/NameMap.h
  include/llvm/DebugInfo/PDB/Raw/PDBFile.h
  include/llvm/DebugInfo/PDB/Raw/RawError.h
  include/llvm/DebugInfo/PDB/Raw/RawSession.h
  include/llvm/DebugInfo/PDB/Raw/StreamInterface.h
  include/llvm/DebugInfo/PDB/Raw/StreamReader.h
  include/llvm/DebugInfo/PDB/Raw/TpiStream.h
  lib/DebugInfo/PDB/CMakeLists.txt
  lib/DebugInfo/PDB/DIA/DIAError.cpp
  lib/DebugInfo/PDB/DIA/DIASession.cpp
  lib/DebugInfo/PDB/GenericError.cpp
  lib/DebugInfo/PDB/PDB.cpp
  lib/DebugInfo/PDB/Raw/ByteStream.cpp
  lib/DebugInfo/PDB/Raw/DbiStream.cpp
  lib/DebugInfo/PDB/Raw/InfoStream.cpp
  lib/DebugInfo/PDB/Raw/MappedBlockStream.cpp
  lib/DebugInfo/PDB/Raw/NameHashTable.cpp
  lib/DebugInfo/PDB/Raw/NameMap.cpp
  lib/DebugInfo/PDB/Raw/PDBFile.cpp
  lib/DebugInfo/PDB/Raw/RawError.cpp
  lib/DebugInfo/PDB/Raw/RawSession.cpp
  lib/DebugInfo/PDB/Raw/StreamReader.cpp
  lib/DebugInfo/PDB/Raw/TpiStream.cpp
  lib/DebugInfo/Symbolize/Symbolize.cpp
  test/DebugInfo/PDB/pdbdump-headers.test
  tools/llvm-pdbdump/llvm-pdbdump.cpp

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D19940.56323.patch
Type: text/x-patch
Size: 70737 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160505/efa83732/attachment-0001.bin>


More information about the llvm-commits mailing list