Consistent data types in columns: how are #ERRORS treated?

This ^ principle (keeping data types consistent in any column, either text or numbers) has greatly improved the performance of my workbooks.

How do #ERROR codes behave here? I have tried ISTEXT and ISNUMBER, and they appear to be neither.

I can force an error code to become like a number, or like text, to make completely consistent data. eg, IFERROR(... , 0) or IFERROR(... , "").

Is this necessary to ensure good performance? Or maybe I don’t need to worry about error codes, if they’re useful?

Thanks.

In general, if you didn’t plan the error on purpose (to be honest, I can’t imagine a situation where this would be justified), then it’s better to get rid of errors immediately after they’re discovered, not try to process them, but rather correct them.
I hope that Bugerra extension will make this task easier for you. Yes, the extension is not perfect, in case of a very large number of errors it works very, very slowly. But in your large table of these errors there are not very many?

SpecialCells » Libreoffice Extensions is really quick with thousands of error ranges

I’m looking for text in text. So I might have a formula, FIND("foo",A1), which I then want to use in logic. LEN(A2) is TRUE if “foo” is found, and #NA if not. I force a return of FALSE by using IFERROR to transform the #NA into 0.

On ranges I’m doing the same with MATCH: I know there is no match if it returns #NA, then IFERROR “normalises” the result.

(COUNTIF will return 0 instead of #NA, but that creates other problems.)

Is this a good approach?

In the case of catching #N/A errors use IFNA() instead of IFERROR() because otherwise the latter suppresses any error that you won’t be aware of.

1 Like

Unfortunately, it is an old spreadsheet traditional that FIND returns #VALUE when it should return 0 or #N/A.
IFERROR(FIND(...);0) returns number 0 in case of no match.
IFERROR(FIND(...);NA()) returns error #N/A in case of no match.

hm… compare the the 3 FormulaRanges in Columns G:I in
ask_113434.ods (15.1 KB)
attached file…