On Fri, 2021-02-26 at 13:53 -0400, George N. White III wrote:
At some point, RFC's need to address error reporting and diagnostics. There is also Java, which spews out 10^2 lines of tracing data with nothing to highlight the line that has the key to the problem.
I suspect the compiler work was driven by academia wanting to reduce the amount of time wasted in student training to deal with useless error messages.
With much of linux development being done by companies that sell support, better error reporting would make it easier for organizations to decide they don't need to pay for support.
I remember one of our lecturers are college commenting how their Data General mainframe put out such a large amount of information in the error messages that it's almost too user friendly.
However, as well as the explanatory comment that you could actually read and understand, it would pop up the offending line of code with the error and park the cursor either at the last point it could cope with, or the first point it objected to (I can't remember back 25+ years). It did make it a lot easier to debug than computers that spew up: error #456.865 your turn, now...
Reminds me of the opaque error code that a friend's Windows computer spewed up when it fell into a nervous breakdown during an attempted update, and nothing further could be done with it until we fixed the unknowable error. We had to look up the code on another computer, and all the damn thing wanted was for us to correctly set the clock. It could have said that. It could have set the clock itself, it was online (and if windows used GMT/UTC it wouldn't matter what the timezone was).