ERRORTYPE Function (LibreOffice Calc)

• Introduced: First release not established; documented by LibreOffice 3.3.
• Supported in: 26.8 Help and 26.8.1.1 native registration; no retirement is established.
• Scope: Desktop Calc, English formulas. The documented ORG.OPENOFFICE.ERRORTYPE name is outside OpenFormula 1.3.
• Checked: October 14, 2026. Function-specific documentation, source and example constraints were checked. No native error display was executed.

This is a diagnostic function for a cell that already has an error. It does not repair the failed calculation or return the cell’s displayed message as text. The returned number identifies Calc’s internal error value. Official Help illustrates the distinction with a cell displaying Err:518: the function returns 518. A string containing the characters “Err:518” is not that error state. Function Help.

ERRORTYPE(Reference)

Reference is the cell whose error you want to inspect. Use a single-cell reference in these examples. The helper has additional reference-handling branches, but this guide does not claim that a multi-cell range produces a list of error codes. A healthy number, ordinary text or genuinely empty cell has no error to report.

The table gives documented or code-derived interpretations, not recorded application results. The stated cell contents are assumptions for reproducing each diagnostic.

Put the formula you are auditing in A1 and put =IF(ISERROR(A1);"Calc error "&ERRORTYPE(A1);"OK") in B1. Keep A1 visible: B1 adds a compact diagnostic without replacing the original failure. Copy B1 downward to inspect corresponding cells in column A. The relative reference changes one row at a time; this is a set of single-cell checks, not a claim about passing an entire range to ERRORTYPE.

If a healthy cell should remain blank in the audit column, change the final "OK" to "". That produces an empty text result in B1; it does not make B1 a genuinely empty cell. Do not use the presence of that formula as a test of whether A1 itself is empty.

ERRORTYPE and ERROR.TYPE are different registered functions. The former returns the underlying Calc error number. The latter maps selected error classes to small standardized categories: for example, the inspected ERROR.TYPE branch maps division by zero to 2 and not-available to 7. Those category numbers are not interchangeable with ERRORTYPE’s internal numbers.

For portable error handling, first decide whether you need to replace a failed result, detect any error, or distinguish an error class. IFERROR, ISERROR and ERROR.TYPE address those different jobs. Keep ERRORTYPE for cases where the native Calc code is useful. Avoid writing a cross-product rule such as “every division error has this ERRORTYPE number” without checking each product’s own contract. Inspected implementation.

The no-error #N/A result is easy to mistake for a new problem in the original cell. It belongs to the diagnostic formula when there is no error code to return. The guarded examples avoid that ambiguity. Do not create a circular reference by putting the diagnostic in the cell it inspects.

The Err:518 examples describe a pre-existing error state, not a formula to manufacture that error. No native error display, localized message, array evaluation or runtime error-code enumeration was executed here. The distinction between real errors and message-looking strings comes from the complete reference helper and callback.

ERROR.TYPE, ISERROR, IFERROR.

• Function-specific Help
• Complete versioned callback
• English native-name registration
• Reference and error-state helper
• Separate ERROR.TYPE category mapping
• ISERROR predicate

The review covers the retained documentation and exact 26.8.1.1 source. No application run is claimed for this guide. The diagnostic assumptions and native error categories remain distinct.