https://bz.apache.org/bugzilla/show_bug.cgi?id=62307
--- Comment #1 from [email protected] <[email protected]> --- Bump. Abstract Cell javadoc: /** * Get the value of the cell as a number. * <p> * For strings we throw an exception. For blank cells we return a 0. * For formulas or error cells we return the precalculated value; * </p> * @return the value of the cell as a number * @throws IllegalStateException if the cell type returned by {@link #getCellType()} is {@link CellType#STRING} * @exception NumberFormatException if the cell value isn't a parsable <code>double</code>. * @see DataFormatter for turning this number into a string similar to that which Excel would render this number as. */ double getNumericCellValue(); The javadoc is missing the following cases: 1. BLANK: implemented in code, returns zero. 2. ERROR: implemented in code, throws ISE (IllegalStateException). 3. BOOLEAN missing from both javadoc and behaves differently depending on the implementation and whether formula is set: formula set | HSSF | XSSF | SXSSF | =================================== no | ISE | ISE | ISE | yes | ISE | cast | ISE | What's the criterion that a cellType is convertible to numeric? These methods are not used by the evaluator (the latter has format-independent conversion logic) but may be used as a part of public API... but for what? I guess the least invasive and most consistent way is to alter XSSF so that calling getNumericCellValue on a cell with BOOLEAN cached result type produced ISE. Maybe it makes sense to prohibit *any* implicit typecasts in Cell#get*Value in the future. Any comments? -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
