Unhelpful error message
Unhelpful error message
beloradu
Posts: 6Questions: 2Answers: 0
Error messages shown: "Uncaught TypeError: Cannot set property '_DT_CellIndex' of undefined"
Description of problem: I was building a new page based on an existing one, plugged everything in, got the error...
Apparently a <td> was missing:
However, the error doesn't describe this; it's cryptic. It doesn't say "table-data missing for table-header" or something intelligent so that I realize what's going on. Before I did an internet search, I tried to trace through the code, which is just as cryptic, scratching my head and debugging and trying to figure out what it was trying to tell me...
This isn't how something this simple should be handled.
There should be an error message clearly describing the problem, not something sending someone on a wild goose chase, to just have to make a forum post, and sift through dozens of comments to figure out what's wrong. Horribly inefficient.
Replies
Harshly put, but I appreciate the feedback and reckognise that it will have been properly frustrating!
I agree that this should be handled in a much nicer way - ideally with a link to one of our tech notes like when invalid JSON is returned from the server for an Ajax request. The error as it is since it is an uncaught error exception - I haven't added any specific error handling code for it. That is an error on my part (I traded code size against friendly error messages).
Allan
I'm sorry if it's harsh, but it was unexpectedly frustrating and time-consuming. I noticed a lot of forum posts about it, so it seems to be a common cryptic error and waste of time for developers. Any error like that should have a specific error.
One concern I did consider however is when to add coder-friendly error messages, and I can see how adding an error message for everything that could fail could junk up the code and make it hard for source contributors to work on it. So I can understand why this one didn't have a friendly message to begin with.
My overall feedback then is that when an issue is posted about enough (like this one has been already), it's an indication of a common problem devs run into, and needs a friendlier response than a cryptic exception.
In this case, one of many solutions would work just fine for it:
- have handling preventing the Exception in a way that bubbles up and makes it clear in the UI what's going on; right now it just doesn't show the table values at all, but having a misalignment or error in a value at least indicates a problem and where to look for it
- a displayed friendly informative error where the problem is (like, table value count mismatch for table headers in table [id] or something like that)
- something less cryptic but more informative; in place of the table data, show a red error or something like that saying "Error: Unable to display table" and then maybe some cleaner code more obvious code or naming conventions for tracing etc
Just some thoughts. I tend to code for any-dev / user readability / intuitiveness, though I can understand a var / function naming convention format that makes sense to the source devs, it shouldn't be too cryptic for a library user to trace without a bunch of forum posts needing explanation nor for a user to get the wrong idea of what's happened (like, nothing showing).
Many thanks. I totally agree - it was something I was aware of a while back and should have done something about, but never got around to it. I've got this thread open in a tab so I can remind myself to work on this (hopefully later today)
Allan
Fix committed here with a link to this new tech note.
Many thanks for prompting me to get this done!
Allan