Most Unhelpful Message Ever
-
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...
-
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 worked with a guy that would litter his code with assert(Date.Now < [next tuesday]), so that he would remember to remove his debug code before it hit production except when he released his assert statements to production. :-D
Curvature of the Mind now with 3D
-
I worked with a guy that would litter his code with assert(Date.Now < [next tuesday]), so that he would remember to remove his debug code before it hit production except when he released his assert statements to production. :-D
Curvature of the Mind now with 3D
Hm, if i remember correct in c++ even if you have asserts in the code in build due of the compiler optimizations they don't get executed with validate . I don't see the problem with putting asserts and validates in code
Microsoft ... the only place where VARIANT_TRUE != true
-
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.
Could be worse.. something like (in C):
/* Should never get here */
exit(0);Now there is a useful error message.. oh, wait! what message? :wtf: The sad thing is that a long time ago I came across a library that did this (just outright exited the program, rather than return an error code to the caller). :sigh:
-
Yeah, that's nice too. I've also come across several completely empty catch statements. Those are fun to debug: "Error? What error?"
-NP Never underestimate the creativity of the end-user.
This is probably because the programmer didn't know how to handle the error or what to do with it.
-
Yeah, that's nice too. I've also come across several completely empty catch statements. Those are fun to debug: "Error? What error?"
-NP Never underestimate the creativity of the end-user.
-
This is probably because the programmer didn't know how to handle the error or what to do with it.
-
Here on Code Project somebody made an excellent point about empty catches: This piece of code
try {
SaveUserData();
}
catch
{
}is equivalent to:
try {
//SaveUserData(); -- if it can fail silently, then why care?
}
catch
{
}Greetings - Jacek
Wow, this post's timing is perfect. I've been tracking down a bug this morning where data is not being saved to a database table when it should be (in the same code that started this thread). It came down to an error being thrown by the database, but caught in an empty catch statement. As frustrating as that is, it has been going on for a couple of years...nobody seemed to care until now, so why bother?
-NP Never underestimate the creativity of the end-user.
-
A message like that actually exists in the BIOS firmware. :doh: (Actually saw it once. On the monitor. :doh: )
brisingr_aerowing@Gryphon-PC $ rake in_the_dough Raking in the dough brisingr_aerowing@Gryphon-PC $ make lots_of_money Making lots_of_money
-
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
Hmmmm I was once interviewed by a person who had asked me "Why are Exceptions Bad?".... Without catching the drift of his tone, I replied "I don't think Exception are bad" .... Interview ended few seconds after that I guess I was lucky that I did not get the Job!!!
-
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.
-
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.
In my C/C++ code I often write similar things: assert statements. ASSERT -> "It should never happen that the specified expression evaluates to false". Of course ASSERT is usually compiled only into some non-release configurations. I use different kind of assert statements, I call one of these the "This should never happen" assert: This is an assert that always fires unconditionally with a specified message when executed. For example assert_message("Unhandled EMode enum member");
enum EMode
{
EMode_mode1,
EMode_mode3,
};void Func(EMode mode)
{
switch (mode)
{
case EMode_mode1:
// blah blah
break;
case EMode_mode2:
// blah blah
break;
default:
assert_message("Unhandled EMode enum member!");
break;
}
}If someone extends the enum with a new member (and lets say the functions that use the enum are not next to the enum in your files) and some codepieces are not updated along with the enum then at least you get a runtime error sooner or later in non-release builds. Of course there are a lot of other places where "This should never happen" asserts are useful.
