https://bugs.documentfoundation.org/show_bug.cgi?id=146377
Eike Rathke <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Version|7.2.4.1 release |Inherited From OOo CC| |[email protected] --- Comment #4 from Eike Rathke <[email protected]> --- Quite.. While the NA() propagates the error, as a condition it never evaluates to TRUE (that's probably what you see as "continues execution with a 0 value"), so the IF()'s else-path is taken that correctly evaluates ISERROR(NA()) to TRUE. The ISERROR() function (like other IS...() error evaluating functions) clears the current nGlobalError because it must not be propagated but the result of the function be pushed instead. I don't see this (error leading to false-path) as a wrong behaviour, though one might argue that already the IF(NA();...) should bail out and execute not even the false-path. Which btw matters only if it contains an error evaluating function. Gnumeric seems to agree and returns #N/A. What does Excel do for this specific case? (In reply to Paul den Hollander from comment #2) > An example: > =AND(NA();1) > =AND(NA();IFERROR(NA();1)) > Result of first formula is #N/A, result of second is Err:504. > > Basically IFERROR can affect the handling of errors that do not originate in > it's parameters. This also seems to happen with the IS* functions, like > ISTEXT, ISNA, etc. E.g.: =AND(NA();IF(ISNUMBER(1);1)) Results in Err:504 Of course the presence of functions that may evaluate error conditions affects until what point an expression is interpreted, that's expected. However, the AND() function (and OR() as well) lacks handling/propagation of error values. It discards unexpected arguments, including error values, and pushes its own Err:504 value. That doesn't happen with =AND(NA();1) because that already doesn't even call AND() as the NA() error would persist. -- You are receiving this mail because: You are the assignee for the bug.
