Description
While working on integration we've noticed [1] that we have to map CellError.type to a human-readable string. Unfortunately, we can't use the translated error message then.
|
errors: { |
|
DIV_BY_ZERO: '#DZIEL/0!', |
|
NAME: '#NAZWA?', |
|
VALUE: '#ARG!', |
|
NUM: '#LICZBA!', |
|
NA: '#N/A', |
|
CYCLE: '#CYKL!', |
|
REF: '#ADR!', |
|
}, |
This should be handled by the engine and exposed as the CellError class property.
|
export class CellError { |
|
constructor(public readonly type: ErrorType) { |
|
} |
|
} |
API Proposal
export class CellError {
public readonly type: ErrorType
public readonly message: string
constructor(type, message = null) {
this.type = type;
this.message = message;
}
/**
* Localized cell value that will be displayed in a worksheet cell renderer
*/
public get value() {
return getLocalizedErrorValue(this.type);
}
}
At first I thought about naming it message property but #VALUE! error can have a custom message returned by the user [2]. So it would be cool to extend the CellError with one more readonly property:
constructor(public readonly type: ErrorType, public readonly message: string) { }
Error types
| Name |
Comments |
| #DIV/0! |
Attempt to divide by zero, including division by an empty cell. ERROR.TYPE of 2 6.13.11 |
| #NAME? |
Unrecognized/deleted name. ERROR.TYPE of 5. |
| #N/A |
Not available. ISNA() applied to this value will return TRUE. Lookup functions that failed, and NA(), return this value. ERROR.TYPE of 7. |
| #NULL! |
Intersection of ranges produced zero cells. ERROR.TYPE of 1. |
| #NUM! |
Failed to meet domain constraints (e.g., input was too large or too small). ERROR.TYPE of 6. |
| #REF! |
Reference to invalid cell (e.g., beyond the application’s abilities). ERROR.TYPE of 4. |
| #VALUE! |
Parameter is wrong type. ERROR.TYPE of 3. |
Reference
[1] https://github.com/handsontable/handsontable/pull/6512/files#r352545073
[2] https://docs.microsoft.com/en-us/office/dev/add-ins/excel/custom-functions-errors
Description
While working on integration we've noticed [1] that we have to map
CellError.typeto a human-readable string. Unfortunately, we can't use the translated error message then.hyperformula/src/i18n/plPL.ts
Lines 42 to 50 in e696d1d
This should be handled by the engine and exposed as the
CellErrorclass property.hyperformula/src/Cell.ts
Lines 79 to 82 in e696d1d
API Proposal
At first I thought about naming it
messageproperty but#VALUE!error can have a custom message returned by the user [2]. So it would be cool to extend theCellErrorwith one morereadonlyproperty:Error types
Reference
[1] https://github.com/handsontable/handsontable/pull/6512/files#r352545073
[2] https://docs.microsoft.com/en-us/office/dev/add-ins/excel/custom-functions-errors