Most Unhelpful Message Ever
-
have to admit that I am guilty of doing this one sometimes. in my defense, I only do this in debug code and I try to not let it go into production. kind of like having a default on switch block used with an enumeration. if you have handled all of the values in your case statements the default should never hit. if default is hit that means someone changes the enumeration or something else really bad happened.
you want something inspirational??
Unfortunately, this is in production code. I've replaced it to throw an error instead, which is what should have been done in the first place. The word "never" is a red flag for me. My experience has been that when ever someone uses the word "never", code for it anyway. It will probably come back to haunt you someday if you don't. In this case, I don't think any users have actually seen this message, but you 'never' know... ;)
-NP Never underestimate the creativity of the end-user.
-
I can beat that - some code I was asked to help with had hundreds of methods where a database query was wrapped with:
try
{
// Some code here...
}
catch (Exception exception) // Gotta catch 'em all!
{
// Take a string property, convert it to a string, and then throw it away:
exception.Message.ToString();// Throw away any meaningful information from the exception,
// and replace it with a mis-spelled pile of elephant dung:
throw new Exception("Exception occured");
}Needless to say, every call to one of these methods was wrapped with:
try
{
// Do a whole bunch of stuff...
CallTheQueryMethod();
// Do a load more crap...
}
catch (Exception exception)
{
// Tell the user something bad happened:
MessageBox.Show(this, exception.Message);
}
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
-
My head hurts from banging it on my desk. Just came across this beauty in the 'else' statement of some code I'm debugging (not mine, of course): MessageBox.Show("Should never get this message."); :doh:
-NP Never underestimate the creativity of the end-user.
What do you think of this? Yesterday I had an exception thrown by the exception handler which caused another... Exception. The log file simply exploded! Had to stop the service.. What was the problem: a new user tried to login without credentials yet saved in the Human Resources DB but already on Active Directory. Why can the HR department be empty when somebody new starts?:mad:
The signature is in building process.. Please wait...
-
My head hurts from banging it on my desk. Just came across this beauty in the 'else' statement of some code I'm debugging (not mine, of course): MessageBox.Show("Should never get this message."); :doh:
-NP Never underestimate the creativity of the end-user.
Actually themessage ought to read: "Something really bad happened". And that's unfinished code. Someone placed this as a marker in the code to be reminded that something more has to be written.
-
My head hurts from banging it on my desk. Just came across this beauty in the 'else' statement of some code I'm debugging (not mine, of course): MessageBox.Show("Should never get this message."); :doh:
-NP Never underestimate the creativity of the end-user.
I still like the ones that you used to see a lot of the form:
_description of the problem_ Cancel this action? [OK] [Cancel]which leaves the user in a complete quandry. Does [OK] mean 'yes,I want to cancel' and [Cancel] mean 'No, please cancel the Cancel'; or does [OK] mean 'continue without cancelling' and [Cancel] mean 'Yes, cancel is what I want to do'? Plus, there is no indication of what dire effects either of thse two options have. -
My head hurts from banging it on my desk. Just came across this beauty in the 'else' statement of some code I'm debugging (not mine, of course): MessageBox.Show("Should never get this message."); :doh:
-NP Never underestimate the creativity of the end-user.
:-) This reminds me of a message that some code of my former employer produced. It was saying "These shoes are to large for you!" every time some absurd socket implementation tried to put large data into a length limited stream and the data was to big. When the original developer returned to the company one day and the developer currently responsible for the code told him what strange error messages one customer was receiving that poor guy said "What?! That message wasn't supposed to be seen by anyone..."
-
Unfortunately, this is in production code. I've replaced it to throw an error instead, which is what should have been done in the first place. The word "never" is a red flag for me. My experience has been that when ever someone uses the word "never", code for it anyway. It will probably come back to haunt you someday if you don't. In this case, I don't think any users have actually seen this message, but you 'never' know... ;)
-NP Never underestimate the creativity of the end-user.
NickPace wrote:
My experience has been that when ever someone uses the word "never", code for it anyway. It will probably come back to haunt you someday if you don't.
I can attest to that. I like to do similar stuff in situations where some kind of assertion looks like the right thing to do, but I cannot think of anything that could happen breaking the assertion. It's my way of saying "I don't expect anything bad to happen here, but I do expect the unexpected!" :cool: (then again, I usually just use
asserts, not message boxes... :doh: ) -
My head hurts from banging it on my desk. Just came across this beauty in the 'else' statement of some code I'm debugging (not mine, of course): MessageBox.Show("Should never get this message."); :doh:
-NP Never underestimate the creativity of the end-user.
I see it's time for the resident dinosaur to ring in...
Way back when -- Was it the Obscene Era, or the Cretinaceous? I forget -- I was attempting a feat that, happily, is no longer important to anyone not yet mummified: channel programming on an IBM 360/67. Channel programming was necessary to do "access method" development for IBM-style disk packs. If you've never seen that phrase before, combine the worst aspects of assembler with completely, deliberately opaque documentation in faded typescript, and remove any trace of debugging facilities. It's possible that no one outside IBM itself has ever understood channel programming; despite my youthful bravado, I never did.
Anyway, I'd misunderstood something in that faded typescript and had gone "one level too indirect" in a data structure critical to my channel program. Accordingly, it crashed the system completely, occasioning a cold-start reboot and bringing the wrath of the system administrators (and quite a few other programmers) down on my poor head. It was a traumatic event, to be sure. But what I'll remember all the way into the afterlife was the error message on my printout:
Channel command error encountered:
Please correct your program before re-running it.I'm told that there are programmers who disdain exceptions and exception handling as "too difficult." Fancy that.
(This message is programming you in ways you cannot detect. Be afraid.)
-
What do you think of this? Yesterday I had an exception thrown by the exception handler which caused another... Exception. The log file simply exploded! Had to stop the service.. What was the problem: a new user tried to login without credentials yet saved in the Human Resources DB but already on Active Directory. Why can the HR department be empty when somebody new starts?:mad:
The signature is in building process.. Please wait...
vonb wrote:
Why can the HR department be empty when somebody new starts?
Simple: the home office downsizes your local HR presence to a single overworked and harassed individual. Despite her angelic personality and the patience of Buddha, sh!t still happens.
Software Zen:
delete this; -
My head hurts from banging it on my desk. Just came across this beauty in the 'else' statement of some code I'm debugging (not mine, of course): MessageBox.Show("Should never get this message."); :doh:
-NP Never underestimate the creativity of the end-user.
I've done something like that too. (And I confess I never cared to take it out of production code. At least I put a bit of comment besides it. And I put in a bit of information where this strange condition occurred, of course.) Sometimes we get errors because the programming environment behaves differently from what the documentation says, and they are among the errors that are hardest to find. And iirc, it was one of these cases when I put in that code (among tons of similar code elsewhere of course). (We even had several times encountered an error that occurs only in production code, but never in debug.)
-
vonb wrote:
Why can the HR department be empty when somebody new starts?
Simple: the home office downsizes your local HR presence to a single overworked and harassed individual. Despite her angelic personality and the patience of Buddha, sh!t still happens.
Software Zen:
delete this;Gary Wheeler wrote:
home office downsizes your local HR presence
The problem is: it is already the home office where I work... And there is a MAIN rule: 50 % office occupation is MANDATORY. Who invented that: HR... :laugh:
The signature is in building process.. Please wait...
-
I still like the ones that you used to see a lot of the form:
_description of the problem_ Cancel this action? [OK] [Cancel]which leaves the user in a complete quandry. Does [OK] mean 'yes,I want to cancel' and [Cancel] mean 'No, please cancel the Cancel'; or does [OK] mean 'continue without cancelling' and [Cancel] mean 'Yes, cancel is what I want to do'? Plus, there is no indication of what dire effects either of thse two options have. -
I've done something like that too. (And I confess I never cared to take it out of production code. At least I put a bit of comment besides it. And I put in a bit of information where this strange condition occurred, of course.) Sometimes we get errors because the programming environment behaves differently from what the documentation says, and they are among the errors that are hardest to find. And iirc, it was one of these cases when I put in that code (among tons of similar code elsewhere of course). (We even had several times encountered an error that occurs only in production code, but never in debug.)
I remember coding basicscript (like vb) for an old Scantron machine. It had the single worst production compiler ever created. For loops would skip steps... If statements with true conditions would be ignored… My code was filled with "this should not happen…", but eventually I had to be specific just for my own sanity.
-
My head hurts from banging it on my desk. Just came across this beauty in the 'else' statement of some code I'm debugging (not mine, of course): MessageBox.Show("Should never get this message."); :doh:
-NP Never underestimate the creativity of the end-user.
I did something similar in a C project while at college which had the message "Bo*****s it shouldn't get here!" and I forgot to take it out when I submitted it.
Every day, thousands of innocent plants are killed by vegetarians. Help end the violence EAT BACON
-
My head hurts from banging it on my desk. Just came across this beauty in the 'else' statement of some code I'm debugging (not mine, of course): MessageBox.Show("Should never get this message."); :doh:
-NP Never underestimate the creativity of the end-user.
NickPace wrote:
Should never get this message.
I prefer "If you see this, there is something terribly wrong."
CEO at: - Rafaga Systems - Para Facturas - Modern Components for the moment...
-
My head hurts from banging it on my desk. Just came across this beauty in the 'else' statement of some code I'm debugging (not mine, of course): MessageBox.Show("Should never get this message."); :doh:
-NP Never underestimate the creativity of the end-user.
Well, this is not a message seen in a piece of software being debugged or modified... does anybody remember that useless message "Keyboard not found. Press F1 to continue." that old BIOS (AMI, I believe) used to show when they could not detect a keyboard? A long time ago, but I've seen them in old 386's and 486's. I know, I know, that was last century. ;)
-
My head hurts from banging it on my desk. Just came across this beauty in the 'else' statement of some code I'm debugging (not mine, of course): MessageBox.Show("Should never get this message."); :doh:
-NP Never underestimate the creativity of the end-user.
-
That's awesome. It's what happens when you feel you need a try but have no clue what to do in the event it ever does fail. Also, it could be that if the developers ever saw it then they knew some approach was not working and could fix it but assumed their approach was right and therefore should never see it.
There are only 10 types of people in the world, those who understand binary and those who don't.
I have gotten some of those before. Had a look at the code and can't see how it could possibly get there. Normally it is an indication that something has gone awry. Possibly stack corruption or something like that. The thing is they don't normally print the if or case bits so you haven't a clue how it got there.
-
Well, this is not a message seen in a piece of software being debugged or modified... does anybody remember that useless message "Keyboard not found. Press F1 to continue." that old BIOS (AMI, I believe) used to show when they could not detect a keyboard? A long time ago, but I've seen them in old 386's and 486's. I know, I know, that was last century. ;)
I've seen that one derided before, and I honestly don't think it's that bad. I read it as "your keyboard isn't plugged in, dolt. When you decide to plug it in, press F1, and I'll continue to do my thing." Maybe they should have phrased it as such.
-
I've seen that one derided before, and I honestly don't think it's that bad. I read it as "your keyboard isn't plugged in, dolt. When you decide to plug it in, press F1, and I'll continue to do my thing." Maybe they should have phrased it as such.
Yes, I agree. Nevertheless, the couple of times I saw this the message itself was useless. Once, the keyboard didn't work and the other was unplugged, but plugging it didn't work until turning off and on...
