https://bugs.documentfoundation.org/show_bug.cgi?id=172799
--- Comment #8 from Ben Urban <[email protected]> --- (In reply to ady from comment #4) > The error codes are based on what devs themselves introduce for each > function, and we already see some inaccurate codes (numbers) in some cases. > If there is no "time" to use adequate error codes, there is less time / > patience / resources to be more accurate in additional explanations, whether > they are displayed on some tool tip or on some other place. I think perhaps you misunderstand. My intention is to add this functionality myself. I do have the time to "waste" on this. Obviously I can't do the translation, but I can certainly expand on most of the error messages that are produced. I filed this feature request to solicit ideas on how this could be improved, and to get feedback on my suggestion in general. > Moreover, the error code is just one (initial) possibility; it does not mean > that the actual error is exactly that one. This is similar to what happens > when Calc claims that there is some typo in a formula (that was just > typed-in) and suggests an alternative; more than once the suggestion does > not match what the user wanted to type-in. IOW, a different mistake / typo > has to be corrected, by the user. I have found that feature frustrating once or twice as well. When I enter a complex formula, it tells me what it thinks it should say, but not what I typed or where the difference is. I *always* reject the suggestions because of that, and hunt for the error myself. I suppose it is helpful for a simple formula that has a simple mistake, but in my formulas it is a totally worthless feature. > It would be a waste of time and resources trying to read users' minds and to > provide additional details om screen when there is no real way to actually > solve the problem. The error code and its message (on the status bar) are > just generic initial hints, that may or may not be accurate. It is up to the > user to investigate, inform himself, analyze the formula and find out what > actually is wrong. This process is improved by experience. Claiming that > Calc can give better and more accurate solutions for this will only cause > users to complain about inaccurate or inadequate information given by Calc. I strongly disagree. I am thinking of this sort of error reporting as being akin to the output generated by a compiler when it detects an error. Considering that the classes involved are literally called FormulaCompiler and ScCompiler, and that the formula language is actually a pure functional programming language, I think this comparison is particularly apt. > As for reading the wiki, users don't always need to go elsewhere to solve > the problem. Again, it is up to experience. The flexibility of spreadsheet > tools is both a strength and a weakness. > > Regarding the current "Formula" tool tip, perhaps there are other tool tips > depending on the type of error; IDK. Perhaps the intention is just to say to > the user "pay attention to the formula in the current cell", as simple as > that, just making the message more "discover-able" for newbies by the mere > appearance of the tool tip. If that's it, I would not recommend changing it; > the only consequence would be to add load to translators with no meaningful > outcome. This is where I am seeing that there could be extra work for someone besides me. I not suggest increasing the load on the translators if I didn't feel it to be worth the effort. The extra effort on a developer's part to add a useful error message each time they add functionality (after I have taken care of existing functionality) is negligible. > I consider this a waste of time. It will not solve any actual problem. If > the user cannot solve the problem with the current info, he will need to get > help elsewhere anyway, whether it is reading something or seeking help from > others. As I stated above, I do have the time to "waste" on this. I would be happy to add this myself. I also believe that it is wrong to expect every user to read a manual to write spreadsheet formulas. Providing unhelpful error messages and then saying "RTFM" is laziness on the part of the developer, plain and simple. I am not, however, accusing the people who have written the error messages that are currently in place of laziness. I was forced to implement such error messages myself, due to the lack of any effective means of providing more information. That's what I'm really getting at, here: the software doesn't offer a way for the developer to generate a more meaningful error messages if they want to. My initial impetus for making this suggestion came when I was creating LAMBDA and related functionality, and found that there was no framework for me to write error messages that provided enough information for me to determine where it was detecting an error, or any details about what it was seeing. While I was working on it, it wasn't even necessarily correct about there being an error, so having to use a debugger just to see that information was quite a pain. -- You are receiving this mail because: You are the assignee for the bug.
