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?
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.