Error handling for
TarFile.extractall currently allows relatively little control over individual issues. Using
errorlevel you can ignore “fatal” or “non-fatal” errors, and using
debug you can optionally log ignored ones to
sys.stderr. If an error is not ignored, it is raised, which aborts the extraction. So, you can’t extract as much as possible and get structured information about what failed.
This sounds like a good use case for exception groups.
My idea for an API:
errorlevel=3turns on exception group reporting: all
Exceptionerrors from extracting individual members are collected, and (if any are found) raised in an ExceptionGroup when the extraction finishes.
memberattribute, which contains the
TarInfoobject for the failed entry
- All other exceptions are “wrapped” in
ExtractError, so that this
memberis always accessible:
exceptionattribute, which contains the exception. In some current cases where
ExtractErroris raised, we’ll need to create an appropriate exception to put here.
If you (yes you!) want to add this to Python 3.13, I can help.
The alternative to wrapping everything in
ExtractError is to subclass
ExceptionGroup to expose the
member <-> error relation in another way. This was discussed in bpo-90589 and discussions leading up to it. But I think wrapping is easier.