pfSense

Although it shouldn't happen, a quick forum check shows that errors used to arise some years ago with bare GUI error messages such as "XML error: LABEL_TEXT at line NNN cannot occur more than once" where NNN is not immediately meaningful to a user.

I just got one of these and traced it to functions in xmlparse.inc and xmlparse_attr.inc. What struck me is that the functions in these two files generate error messages - but not helpful ones.

"XML error" isn't immediately tied to something the user knows to be happening since XML tends to be internal. "LABEL_TEXT" will be an XML item, again internal and unlikely to be known to most users. The line number isn't a line in current code but a line in the XML parsed data, which is a transient line number often in a transient datastream, and lost at error generation, and again not something the user could identify usefully. There is no indication what else this could mean or how it's been generated to help a user debug, or seek meaningful help.

Bug hunters often can't help very much or do more than "tell us again if you find out more", when almost no information can be obtained and the user is not skilled in PHP.

Bug request:

1) Can a better system of error handling be standardised in the codebase. Perhaps as simple as log_error() containing an optional arg to add an abbreviated call stack trace to the log so the log at least shows where an obscure error originated and give bug hunters a better chance to locate the issue.

2) can particular attention be paid to ensure that, when an error kills the usual GUI output (as these errors from the XML parser do), or the error is in a ".inc" file, the user is left with a sensible set of debug data on a white screen and not a "one liner" of a single sprintf() without solid debug info, as was the case here. For example the actual line number or codebase function which raised the error would be helpful but it's not in these messages.

A good quality error message handler, especially one able to appropriately trap die() or termination or other fatals to ensure proper debug info will always be shown/logged, would be very useful all round. We don't have that - yet!