https://bugs.documentfoundation.org/show_bug.cgi?id=172799
--- Comment #9 from ady <[email protected]> --- (In reply to Ben Urban from comment #7) > (In reply to ady from comment #6) > > (In reply to Ben Urban from comment #3) > > What's the goal / aim / need of "Not a function"? How is that different > > from the good ole "#NAME?" error? > > When I was adding the ScCall functionality, it needed a way to report that > the user tried to use it on something that wasn't a function. I don't see > how #NAME? applies there, given that names are not necessarily involved (nor > should they be). Error:525 aka "#NAME?" simply means that Calc does not recognize the term that is used in the formula bar (e.g. a typo in the name of a function, among several other cases). There are also similar cases for macros and add-ins, with their own error codes. I don't see any utility in splitting hair by introducing yet another error code that has essentially the same implications. Other spreadsheet tools manage a greater amount of functions with less error codes. There are enough built-in functions in Calc already failing in certain cases, from countif, match, type, datevalue, autocalculation... I still do not see how adding more and more guessing-info on screen for error codes will actually help users. The user has to learn how to use the functions, and how to identify his own errors. By spoon-feeding (which would only be a best case, if the displayed info turns out to be actually accurate and relevant), the learning curve is not easier, but harder. Instead, solving the failing (cases of) functions would actually help much more; users would actually be able to trust the results in Calc. Regarding the users having to search for info (RTFM or wiki or whatever), the info provided is the only way to correctly use the functions. The correct syntax and constraints (which can always be improved, although more info is not always an improvement) can be documented, but documenting possible incorrect cases would never end. Sometimes the error is simple enough to spot (e.g. a comma instead of a semicolon), and sometimes there is no choice but to search for the expected syntax and relevant constraints / limitations. As always, feel free to use your time as you wish. -- You are receiving this mail because: You are the assignee for the bug.
