Coding tip: Learn to read stuff
-
-
@Mason_Wheeler tl;dr
-
But more seriously, I've wanted to scream at people at work for similar things.
-
: I have a problem with your code. It says there's an Error.
: What did the error message say?
: Oh! Thank you…
-
@dkf said in Coding tip: Learn to read stuff:
: I have a problem with your code. It says there's an Error.
: What did the error message say?
: Oh! Thank you…I run into this with my pupils on a regular basis. Quite frequently without the last step, though.
-
@dkf said in Coding tip: Learn to read stuff:
: I have a problem with your code. It says there's an Error.
: What did the error message say?
: Oh! Thank you…I don't know.
-
@dkf
I dodged an ULTRA HIGH PRIORITY TICKET THAT'S BLOCKING THE HOSPITAL by replying if they could kindly send us the error list under the 'print error list' button clearly visible in the screenshot they send, yes right below the box saying number of errors: 113, so I could advise on how precisely they could solve the listed errors, eg if they should follow the manual page 5 or 6.
For extra fun they created the ticket after office hours and proclaimed it should be fixed at their shift start, or around 1h30 before the start of our office hours and thus even before SLA start but that was before I lowered the priority to something normal. Oh ... and since this is an administrative support application we don't offer any out of office hours support.
-
@Rhywden said in Coding tip: Learn to read stuff:
I run into this with my pupils on a regular basis. Quite frequently without the last step, though.
Help forums:
: I have a problem my code. It says there's an Error.
: What did the error message say?
...
...
...
: crickets
...
...
...I guess they fixed it...?
-
I think this is a subset of a problem I've noticed with some junior programmers: they don't know that they're doing.
I don't mean that as in they don't have the necessary knowledge. Worse. They do have the knowledge but due to their inattentiveness they don't apply it.
Sometimes it's as simple as clicking a button to show you the errors, other times it might be a bit more difficult and involve spending two minutes looking at who's calling a function before you start messing with it.
Close whatever YouTube video, Twitch stream, podcast, Discord, or whatever else is running on the second monitor for five minutes and properly focus on the problem.
-
It helps when your error messages are actually informative. Damned near every project I haven't had control of prints either "oops something happened try again later" or a red ASP.NET stack trace. Unless, of course, it's a JavaScript "application" and just stops executing altogether. Those people should be drug out into the street and shot.
(Win32 is 99% of the way to where it should be. Every function returns an error code and those error codes can be translated by another function. All that's really missing sometimes is the details like what file couldn't be found. There's zero excuse for the idiocy of useless error messages.)
-
Maybe some have already seen that video soccpuppet put on twitter (https://t.co/fa1tJegZW8) comparing "what people think programming is vs. how it actually is".
"How it actually is" appears to be: try and run, get an error message, and immediately copy the error message into Google.
-
@Mason_Wheeler said in Coding tip: Learn to read stuff:
https://medium.com/@masonwheeler/learn-to-read-stuff-754ece715db3
So many
programminglife problems can be solved simply by reading and paying attention to information that‘s right there, freely made available to you.
-
@Zenith said in Coding tip: Learn to read stuff:
Win32 is 99% of the way to where it should be. Every function returns an error code and those error codes can be translated by another function. All that's really missing sometimes is the details like what file couldn't be found. There's zero excuse for the idiocy of useless error messages.
Filed under: KeyNotFoundException
Edit to clarify: I do know the difference between Win32 and .Net
-
@Zenith said in Coding tip: Learn to read stuff:
All that's really missing sometimes is the details like what file couldn't be found.
The problem's at its most acute in something like launching an application or loading a DLL, when it's very possible for a fault to be highly indirect.
-
@Zenith said in Coding tip: Learn to read stuff:
It helps when your error messages are actually informative. Damned near every project I haven't had control of prints either "oops something happened try again later" or a red ASP.NET stack trace. Unless, of course, it's a JavaScript "application" and just stops executing altogether. Those people should be drug out into the street and shot.
Had this just now when trying to install a loadbalancer for our BigBlueButton instances. At one point the logs for nginx just stated: "Connection refused" but not what was behind the refusal.
It then turned out that their loadbalancer config allowed to set the port to something other than 3000 (which I was already using so I set it to 3001) but
someonean idiot of the highest order had simply hardcoded the port number 3000 somewhere so the whole thing barfed.
-
@Zenith said in Coding tip: Learn to read stuff:
Win32 is 99% of the way to where it should be.
It's also over 20 years old, and based on 16-bit WinAPI that's like 30 years old. Those were different times.
It's like, people have initially assumed without evidence that releasing buggy crap is bad - but then looked at actual results, concluded it's not true, and have given up on quality from then on.
-
@Zecc said in Coding tip: Learn to read stuff:
@Zenith said in Coding tip: Learn to read stuff:
Win32 is 99% of the way to where it should be. Every function returns an error code and those error codes can be translated by another function. All that's really missing sometimes is the details like what file couldn't be found. There's zero excuse for the idiocy of useless error messages.
Filed under: KeyNotFoundException
Are you giving that as an example of a good error message that states exactly what the problem is, or is it an example of an error that could have more detail (namely, what key wasn't found).
-
@Gąska said in Coding tip: Learn to read stuff:
It's like, people have initially assumed without evidence that releasing buggy crap is bad - but then looked at actual results, concluded it's not true, and have given up on quality from then on.
Back when there was no easy / cheap way to update stuff that's out in the wild the trade off was different.
-
@djls45 said in Coding tip: Learn to read stuff:
Are you giving that as an example of a good error message that states exactly what the problem is, or is it an example of an error that could have more detail (namely, what key wasn't found).
Yes.
(the latter)
-
A problem of course is relying on an error code that gets expanded to a readable message later (you can read "error code 0x80004005", right?); there's no parameterisation to allow it to say anything specific (what file is missing?). That's why structured exceptions are a thing (the structure, if not the mechanism).
Another problem is putting too much information into error messages so that they become attack debuggers.
-
@Watson I took a phony
security course a few years ago and half of it was justifying "oops something happened." I feel like the intended audience for it was H1Bs that don't have any middle ground between that and "wrong password for user with SSN 186-94-2730 in Pentagon section 5."
-
@Zenith information relayed to the user needs to be a balance between not showing too much to help an attacker, showing enough to help the user what they did wrong and how to fix it (or what to tell support if it's not a problem between keyboard and chair), and not showing so much information it scares them. Where this balance should be depends on what the system and application are, and it's probably fair to say very few error messages get it right.
Logs should include as much data as is feasible without exposing pii
-
@Jaloopa said in Coding tip: Learn to read stuff:
Logs should include as much data as is feasible without exposing pii
Sometimes, you have what I refer to these days as bacon alerts, after this example in our codebase.
if (very_rare_condition) log_debug("BACON!");In theory this could be a debugging trap. In practice, it can't because it's running in an environment where we can't attach a debugger (but can pull the logs off). They're only really a problem when they make it into the production version of the code. (
BACONis a team joke.)
-
-
@Jaloopa said in Coding tip: Learn to read stuff:
@Zenith information relayed to the user needs to be a balance between not showing too much to help an attacker, showing enough to help the user what they did wrong and how to fix it (or what to tell support if it's not a problem between keyboard and chair), and not showing so much information it scares them. Where this balance should be depends on what the system and application are, and it's probably fair to say very few error messages get it right.
In the situation where it was something the server (not the user) did wrong, it's best to just to give them a reference number they can provide to support, who can then use it to see the technical details (and relay it to IT to fix).
-
@Jaloopa The problem is that phony "security" training assumes that the only two options are "oops something happened" and a wide open system where knowing today's date is an all-access pass. If you design the system properly, you don't have to worry about providing a few parameters because they're not a vector for attack. If you don't, well, that's on you, not a "dangerous" error message.
@dangeRuss said in Coding tip: Learn to read stuff:
@Zenith said in Coding tip: Learn to read stuff:
drug out
Shirley you mean dragged out?
-
@Zenith said in Coding tip: Learn to read stuff:
@Jaloopa The problem is that phony "security" training assumes that the only two options are "oops something happened" and a wide open system where knowing today's date is an all-access pass. If you design the system properly, you don't have to worry about providing a few parameters because they're not a vector for attack. If you don't, well, that's on you, not a "dangerous" error message.
@dangeRuss said in Coding tip: Learn to read stuff:
@Zenith said in Coding tip: Learn to read stuff:
drug out
Shirley you mean dragged out?
-
@dangeRuss said in Coding tip: Learn to read stuff:
@Zenith said in Coding tip: Learn to read stuff:
drug out
Shirley you mean dragged out?
Next you'll be saying that "snuck" isn't a word
-
@Zenith said in Coding tip: Learn to read stuff:
the only two options are "oops something happened" and a wide open system where knowing today's date is an all-access pass. If you design the system properly, you don't have to worry about providing a few parameters because they're not a vector for attack. If you don't, well, that's on you, not a "dangerous" error message.
Yeah, if you treat your inputs correctly, you don't have to worry about error messages like:
Failed to connect to database with connection string
Server=prod-db.initech.com;Database=hr;User Id=sa;Password=hunter2;. Connection failed.
If you design the system properly,
Filed under: At least they starred out the password.
-
@error said in Coding tip: Learn to read stuff:
@Zenith said in Coding tip: Learn to read stuff:
the only two options are "oops something happened" and a wide open system where knowing today's date is an all-access pass. If you design the system properly, you don't have to worry about providing a few parameters because they're not a vector for attack. If you don't, well, that's on you, not a "dangerous" error message.
Yeah, if you treat your inputs correctly, you don't have to worry about error messages like:
Failed to connect to database with connection string
Server=prod-db.initech.com;Database=hr;User Id=sa;Password=hunter2;. Connection failed.If you let unchecked exceptions fly all the way up to the top of the stack, then you deserve what you get.
If you design the system properly,
Yeah, I am serious. I built a system with a custom stack trace. Between it and the log, I never needed to touch a debugger. That framework cobblers don't understand it is their problem. Speaking of framework cobblers, with all of the time they "save" not writing a handful of ADO statements or putting brackets on separate lines or testing, why does it take them so long to do anything? I swear, watching some of them "think" is like watching a Dodge Neon try to haul a battleship up Mt Everest. The wheels are spinning but nobody's going anywhere...
-
@Zenith You have the luxury of getting to design the systems you work on. The things I work on are labyrinthine Eldritch horrors built a decade ago by people who've long since left, with enough twisty passages that I don't think any one developer has seen their entirety. They weren't really designed so much as they coalesced from chaos over the aeons.
Filed under: But I Press X to Doubt you've ever properly designed a system anyway.
-
@error said in Coding tip: Learn to read stuff:
@Zenith You have the luxury of getting to design the systems you work on.
Perversely, mostly at the front of my career. Now I just get to say "I told you so" over and over.
Filed under: But I Press X to Doubt you've ever properly designed a system anyway.
Depends what you mean by designed. Established a structure and rules, yes. Tossed buckets of word salad that nobody ever read before it disappeared into the darkest corners of ShitPoint, no. Most of the "architects" I've worked with can barely tell you their application runs on a computer.
-
@Luhmann said in Coding tip: Learn to read stuff:
I dodged an ULTRA HIGH PRIORITY TICKET THAT'S BLOCKING THE HOSPITAL by replying if they could kindly send us the error list under the 'print error list' button clearly visible in the screenshot they send, yes right below the box saying number of errors: 113, so I could advise on how precisely they could solve the listed errors, eg if they should follow the manual page 5 or 6.
Let me get this straight. You built software with a 'print error list' button. You then wrote page 5 (or 6) of the manual telling the user how to use said button to get the details of the error to the support team. You did all this instead of either directly sending the error to the support team (if possible), or storing the error in a safe location so the support team can go get it themselves (if call-home is verboten due to security).
And now it's the users fault for not reading the page that should have never been written and not doing the procedure that should never need to be done?
This reminds me of a situation at work where the first time a support ticket came in for our new mobile app was the first time anyone considered esoteric things like "logging".
-
@Jaime I'm guessing that the errors were more of the ID10T type. The program functions fine if you actually give it valid data it can work with, in the format it says it expects.
-
@Benjamin-Hall
That still fits in the same category. If you were reasonably proactive and limited a numeric field to only digits, but some ID10T managed to put four billion in a field that was backed by an int, then don't write a man page chastising people. Realize that you missed an edge case and put the two lines of code necessary to detect this and show the normal invalid UI warnings rather than throwing an exception. It takes less time and makes for a better product and a better relationship.
-
@Jaime said in Coding tip: Learn to read stuff:
@Benjamin-Hall
That still fits in the same category. If you were reasonably proactive and limited a numeric field to only digits, but some ID10T managed to put four billion in a field that was backed by an int, then don't write a man page chastising people. Realize that you missed an edge case and put the two lines of code necessary to detect this and show the normal invalid UI warnings rather than throwing an exception. It takes less time and makes for a better product and a better relationship.If you're doing a web app, sure. But there are lots of ways that you can pass bad data into things.
And I don't see the description as "exceptions with crashes", I see those as exactly validation errors. You input a chunk of work (probably in a batch process, because manually inserting dozens of records one at a time is wack) and get a list of "hey, you screwed up the formatting in XYZ place, go fix it" errors back. And if you're too stupid to look at that list and start working through your ID10T errors, that's on you.
-
@Jaime said in Coding tip: Learn to read stuff:
@Benjamin-Hall
That still fits in the same category. If you were reasonably proactive and limited a numeric field to only digits, but some ID10T managed to put four billion in a field that was backed by an int, then don't write a man page chastising people. Realize that you missed an edge case and put the two lines of code necessary to detect this and show the normal invalid UI warnings rather than throwing an exception. It takes less time and makes for a better product and a better relationship.Yes, if it's all as simple as your strawman, which it could be. Only one of us has seen @Luhmann's application.
-
@Jaime sending the errors to support team would be useless, since the only person who can fix the input data is the one who input the data.
You REALLY REALLY REALLY don't want the hospital administration program to try to fix errors for you automatically.
-
@Gąska said in Coding tip: Learn to read stuff:
@Jaime sending the errors to support team would be useless, since the only person who can fix the input data is the one who input the data.
You REALLY REALLY REALLY don't want the hospital administration program to try to fix errors for you automatically.
No, I probably wouldn't. But if support needs to get messages from a user... I wouldn't use email and meatbags as intermediate links. I'm not suggesting the software fix anything, I'm suggesting the support team improve their means of communicating. That's supposed to be the advantage of bespoke software: you can make it fit your workflow instead of fitting your workflow to the software.
-
@Jaime said in Coding tip: Learn to read stuff:
@Gąska said in Coding tip: Learn to read stuff:
@Jaime sending the errors to support team would be useless, since the only person who can fix the input data is the one who input the data.
You REALLY REALLY REALLY don't want the hospital administration program to try to fix errors for you automatically.
No, I probably wouldn't. But if support needs to get messages from a user... I wouldn't use email and meatbags as intermediate links. I'm not suggesting the software fix anything, I'm suggesting the support team improve their means of communicating. That's supposed to be the advantage of bespoke software: you can make it fit your workflow instead of fitting your workflow to the software.
If a user says "Hey, the widget didn't get frobnicated" and the reason is that the user didn't click the "frobnicate me" button, the user, not the program, is at fault.
Not all errors are programming errors. And users contact support about lots of things where the reason is that they didn't follow the workflow as they were supposed to. Out of ignorance, stupidity, laziness, whatever. Doesn't matter. But the response from support shouldn't be "ok, we'll change the workflow (which is designed the way it is for a reason that the user doesn't have control over)", it's "hey, stop doing that. RTM."
-
@Jaime error messages often contain potentially sensitive information (e.g. the value that caused the error - it might be someone's name or part of medical history, and you can't even check what it is because it just failed validation!), so automatically sending it home for analysis is liability hell. Among other reasons why it's a bad idea.
I think you're reading too much into the manual thing. The error is probably self-descriptive enough, and the manual is probably the usual tautological series of instructions such as "if the error says the name is too long, it's because the name is too long" that manuals are so very fond of. Support team redirects you to manual not because it's useful to you, but because they're ordered to always redirect you to manual if the error is described in manual and would get in trouble with their bosses if they simply said "read the fucking error".
-
@Gąska I hope you realize that any attempt to make a user base smarter is doomed to fail. If people aren't reading the current messages, then do some A/B testing and figure out what works for them.
-
@Jaime Which is why I directed the original post specifically at programmers. If you're going to be one of the people building these systems, you need to hold yourself to a higher standard than the typical user.
-
@Jaime said in Coding tip: Learn to read stuff:
@Gąska I hope you realize that any attempt to make a user base smarter is doomed to fail. If people aren't reading the current messages, then do some A/B testing and figure out what works for them.
Sure, than get told by management that it will be in a release sometime next decade and the customer tells you that they will deploy it sometime in the decade after that.
-
@Jaime
Nope, nope and nope.
It's a decades old LOB that is throwing back a list of data errors to users to fix before they are allowed to perform certain end of year steps. Like 'hey dofus you entered this article price with a certain date range but you ended up with orders without a price. Set them as free or assign a price.' Or 'bitch, you set bookkeeping references that are not valid in your books in that time frame.' So the manual tells them how to fix their shit but since reading is wizardry they need an application Lord to help them point out their fuckery.
The batch editing mentioned further is pretty close to reality. They are performing an end of year check that allows them to have a list that is accepted by the bean counters.
In an ideal world customers would use a workflow that prevents this shit, reality is how ever full of people who don't mind shooting in their own foot every other day as long as it saves a few minutes on the other days.
Both samples above are not bad in their own. Stuff is done by different people at different application parts or even different applications at different times.
So I neither wrote a single code line in this, I don't even know the crusty language used, or the manual. And per the new organization I appear to have been promoted as team lead of the zero member team supporting this thing while the only real dev left is send into the dessert turning this turd into a SaaS turd.
I don't need automatical messages telling my about data errors I can't fix and aren't legally allowed to fix, What would that accomplish?
And yes given our customers it's practical always an GDPR violation. Or HiPPA if you understand that better.
-
@Luhmann it's HIPAA.
-
@Jaime said in Coding tip: Learn to read stuff:
you can make it fit your workflow instead of fitting your workflow to the software.
In theory, you can have a perfect definition of "your workflow" that the software can then support, but I've never seen that in practice.
-
-
@Watson said in Coding tip: Learn to read stuff:
A problem of course is relying on an error code that gets expanded to a readable message later (you can read "error code 0x80004005", right?); there's no parameterisation to allow it to say anything specific (what file is missing?). That's why structured exceptions are a thing (the structure, if not the mechanism).
Another problem is putting too much information into error messages so that they become attack debuggers.
I don't really know about win32 (I have switched platforms back when it was "oooh, 32 bits, that's HUGE"), but db2 uses error codes with parametrization.
SQLCODE=-204, SQLSTATE=42704, SQLERRMC=DB2ADMIN.TESTTABLE SQLCODE=-407, SQLSTATE=23502, SQLERRMC=IDJust says everything that's needed.
Of course, you can enable verbose user-friendly, localized messages, but
who needs that? Especially when the locale is 
Nem tudom magyarom, tudom SQLERROR-om
-
@dkf said in Coding tip: Learn to read stuff:
@Jaloopa said in Coding tip: Learn to read stuff:
Logs should include as much data as is feasible without exposing pii
Sometimes, you have what I refer to these days as bacon alerts, after this example in our codebase.
if (very_rare_condition) log_debug("BACON!");In theory this could be a debugging trap. In practice, it can't because it's running in an environment where we can't attach a debugger (but can pull the logs off). They're only really a problem when they make it into the production version of the code. (
BACONis a team joke.)Personally I would an exception so that everyone would know about it but each to their own.
?