[Bug 66576] New: It is difficult to handle files with wrong formats

[bu...@apache.org]

https://bz.apache.org/bugzilla/show_bug.cgi?id=66576

            Bug ID: 66576
           Summary: It is difficult to handle files with wrong formats
           Product: POI
           Version: unspecified
          Hardware: PC
            Status: NEW
          Severity: normal
          Priority: P2
         Component: POI Overall
          Assignee: dev@poi.apache.org
          Reporter: zhonghao@pku.org.cn
  Target Milestone: ---

Although POI defines InvalidFormatException, when XSSF encounters files with
wrong formats, it hides this exception and throws IOException. For example,
XSSFWorkbook has the following code:

 public int addOlePackage(byte[] oleData, String label, String fileName, String
command)
            throws IOException {
        final XSSFRelation rel = XSSFRelation.OLEEMBEDDINGS;

        // find an unused part name
        OPCPackage opc = getPackage();
        PackagePartName pnOLE;
        int oleId;
        try {
            oleId = opc.getUnusedPartIndex(rel.getDefaultFileName());
            pnOLE = PackagingURIHelper.createPartName(rel.getFileName(oleId));
        } catch (InvalidFormatException e) {
            throw new IOException("ole object name not recognized", e);
        }

Indeed, I notice that POIXMLDocument even bypasses thrown
InvalidFormatException:

 public static OPCPackage openPackage(String path) throws IOException {
        try {
            return OPCPackage.open(path);
        } catch (InvalidFormatException e) {
            throw new IOException(e.toString(), e);
        }
    }

Do POI developers have plans to deprecate InvalidFormatException? Shall I catch
IOException to handle files whose formats are wrong?

Meanwhile, I find that other APIs hide IOException and throw
InvalidFormatException. For example, EncryptedTempFilePackagePart of OOXML has
the following code:

 public boolean load(InputStream is) throws InvalidFormatException {
       try (OutputStream os = getOutputStreamImpl()) {
            IOUtils.copy(is, os);
       } catch(IOException e) {
            throw new InvalidFormatException(e.getMessage(), e);
       }

       // All done
       return true;
    }

As another example, ZipEntrySource has the following code:

protected PackagePartCollection getPartsImpl() throws InvalidFormatException {
  ...
try {
                this.contentTypeManager = new ZipContentTypeManager(
                        zipArchive.getInputStream(contentTypeEntry), this);
            } catch (IOException e) {
                throw new InvalidFormatException(e.getMessage(), e);
            }
}

It is quite confusing. It is also difficult for programmers like me to
implement handling code. Can POI throw consistent exceptions, when file formats
are wrong?

-- 
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@poi.apache.org
For additional commands, e-mail: dev-help@poi.apache.org

[Bug 66576] Throw exceptions are inconsistent when file with wrong formats are encountered

[bu...@apache.org]

https://bz.apache.org/bugzilla/show_bug.cgi?id=66576

Dominik Stadler <do...@gmx.at> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 OS|                            |All
            Summary|It is difficult to handle   |Throw exceptions are
                   |files with wrong formats    |inconsistent when file with
                   |                            |wrong formats are
                   |                            |encountered
           Severity|normal                      |enhancement

--- Comment #1 from Dominik Stadler <do...@gmx.at> ---
There is likely no overall plan how exception handling should work and thus it
developed in an inconsistent way over time. 

We could try to more consistently throw InvalidFormatException, but as it is a
checked exception, this would mean backward-incompatible changes in a number of
APIs.

-- 
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@poi.apache.org
For additional commands, e-mail: dev-help@poi.apache.org