Most Unhelpful Message Ever
-
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.
-
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:
There are several different kind of runtime errors that are fatal and unpractical to handle in your code. Some of these errors (like null pointer exception/access violation/SIGSEGV/SIGBUS and similar fatal errors) must be handled by your top level crash/exception/signal handlers. Some other errors (like can't create thread, out of memory) are practical to handle by calling your own critical error handler function like CRITICAL("Couldn't create thread!"). This critical handler never returns, logs an error message or shows a messagebox and debugbreaks or terminates the program depending whether you run the program in a debugger or not. What would you do if you call the Start() method of a thread and it returns false??? In most programs you simply cant handle such serious errors so its better to return with nothing (void) from the Start() method and to handle the error inside the Start() method by calling CRTICAL(). What do you do if the pthread_mutex_init() or pthread_mutex_lock() call fails??? Because these have return value! In my opinion these functions shouldn't return anything because handling these errors is impractical, the library should inform you with some debug breaks or internal critical handlers. For example in debug builds/debug sessions pthread_mutex_destroy() should debug break in debug sessions or log/fatal exit in release if you try to destroy a mutex that is held by a thread, pthread_mutex_init should also do the same. I convert these errors to CRITICAL() in my encapsulated mutex classes. CRITICAL() is a much better approach then seeing the accumulating code that dumbly tries to handle for example thread creation errors here and there (usually untested error handlers that would crash or deadlock sooner or later after an unsuccessful thread creation). Same is true for memory management. If these errors happen than something really wrong is going on with the machine/OS. Instead of handling these errors its better to write and design the program to operate well if the given amount of resources are available (memory, video memory, cpu performance, free disk space, ...) Probably that exit(0) code should be replaced with a CRITICAL() call.
-
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
But an assert usually isn't compiled into release builds. One of our projects currently using debug, profile and release (and sometimes more) configs internally. relase: obvoius. profile: builds used by the qa and internal workers. this is essentially a release build with optimizations but asserts are on. debug: obvious. Whenever possible its better to put in compile time errors/static asserts. In my opinion the assert you described should be a comment, a tagged task or TODO. I usually mark such codepieces with "// TODO:" or "// HACK:" or "// FIXME:" or "// TRON_TODO:" if I want to differentiate this from others' todo tags. This is easy to find with a global search in any language. In eclipse you can define your own tasks and the "tasks" view is able to collect these tags when you compile/autocompile your java code...
-
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
In release builds usually NDEBUG is defined and with NDEBUG defined assert macros expand to nothing.
-
Perhaps more unhelpful is an error message that was context related and then got copy-pasted into a totally unrelated function i.e "Error in function A!" when it is really in function B :^)
In C/C++ this can be solved by LogError("Error in function %s!", __FUNCTION__);. A better solution is to do logging with macros that has several advanatages: you can easily remove logging depending on log level (for example you can remove only LOG_WARNINGS but leaving LOG_ERRORS in code in release builds) and you can easily collect filenames, line numbers and function names automatically:
#if LOG_WARNING_ENABLED
#define LOG_WARNING(format, ...) g_Logger.Log(ELogLevel_Warning, __FILE__, __LINE__, __FUNCTION__, format, ##__VA_ARGS__)
#else
#define LOG_WARNING(format, ...)
#endif// TODO: LOG_ERROR, LOG_DEBUG, ....
-
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. ;)
+5 I've almost forgot this lovely message! :-) Still, it is a good error message because it points out the problem immediately. The (automatically displayed) second sentence is very funny, I wouldn't have invested any effort to remove it... :-) :-) :-)
-
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
This just shows the incompetence of the programmer who wrote it: he didn't understand a core feature of the used language: exception handling/propagation. The result is extremely hard time or mission impossible when it comes to finding bugs especially from user error reports (without stacktrace of course). If you get a job and you see code like this I recommend doing the following: - ask someone whether a total refactorization is possible (maybe not because of time, safe-player boss, ...) - if refactor is not possible then search for your next job Working on such a codebase is a waste of time from your valuable life.
-
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!!!
Well, it depends on the language and the scenario. I personally love exception handling but in some cases I avoid using exceptions. For example in C++ I don't like it because the rules are too loose (you can throw by value, reference, pointer, there is no standard exception base class/exception chaining): the result is that most libraries simply don't use it or use it only internally. If you have to wire together several libraries with their own exception types that can also be a pain in the ass. Another scenario where the presence of exception handling sometimes matters is extremely performance critical, maybe low level code. One of my friend told me a tale about one of his job interviews. The interviewer ask him the following question: "What is the purpose of smart pointers?". Of course my friend told a tale about object ownership and resource allocation/deallocation. Finally the interviewer gave him the right answer: "Smart pointers are useful because of the exceptions!". :-) :-) :-) It clearly shows the incompetence of the iterviewer, he simply didn't understand that smart pointers are just a possible application of RAII, and he has no clue about object ownership, RAII,...
-
All programming is about handling errors. A whole life is about handling errors, actually. I bet the programmer was a no-lifer. ;)
Greetings - Jacek
:thumbsup:
-
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
But at least it compiles, doesn't it??? :-) :-) :-) I think some people use exceptions only when they have to. For example in java your code wouldn't compile without catching it or declaring the exception in the signature of the function that encloses your code. Result: people catch it and either ignore it or "return false;" or "return null;". Problem solved.
-
There are several different kind of runtime errors that are fatal and unpractical to handle in your code. Some of these errors (like null pointer exception/access violation/SIGSEGV/SIGBUS and similar fatal errors) must be handled by your top level crash/exception/signal handlers. Some other errors (like can't create thread, out of memory) are practical to handle by calling your own critical error handler function like CRITICAL("Couldn't create thread!"). This critical handler never returns, logs an error message or shows a messagebox and debugbreaks or terminates the program depending whether you run the program in a debugger or not. What would you do if you call the Start() method of a thread and it returns false??? In most programs you simply cant handle such serious errors so its better to return with nothing (void) from the Start() method and to handle the error inside the Start() method by calling CRTICAL(). What do you do if the pthread_mutex_init() or pthread_mutex_lock() call fails??? Because these have return value! In my opinion these functions shouldn't return anything because handling these errors is impractical, the library should inform you with some debug breaks or internal critical handlers. For example in debug builds/debug sessions pthread_mutex_destroy() should debug break in debug sessions or log/fatal exit in release if you try to destroy a mutex that is held by a thread, pthread_mutex_init should also do the same. I convert these errors to CRITICAL() in my encapsulated mutex classes. CRITICAL() is a much better approach then seeing the accumulating code that dumbly tries to handle for example thread creation errors here and there (usually untested error handlers that would crash or deadlock sooner or later after an unsuccessful thread creation). Same is true for memory management. If these errors happen than something really wrong is going on with the machine/OS. Instead of handling these errors its better to write and design the program to operate well if the given amount of resources are available (memory, video memory, cpu performance, free disk space, ...) Probably that exit(0) code should be replaced with a CRITICAL() call.
While there are certainly some errors that can't be handled well/predictable (e.g. if memory was corrupted by a buffer overrun, then attempting to even show an error dialog may cause yet another error). But I don't think aborting the program should be done just because a thread couldn't be created (since it is generally an initialization error, like opening some required and missing resource file, not corruption making the running image unstable). If it was a problem beyond that (machine hardware or OS failing), then it doesn't really matter what any application does since you are likely going to have to hardboot your system anyway. If I was using some editing application that internally spawns threads to perform certain [user triggered] operations, I don't want it exiting and loosing all my in-memory edits just because it couldn't create a thread to perform an operation that has yet to be run. I'd want an error message so that I have a chance to save my work and possibly restart the program. Worst case is trying to save also fails with another error and I'm out of luck, but otherwise being able to save is a better option. And if the pthread functions failing was really such an unpassable wall, then why would they even return error codes at all and not abort the program for you? It is because they expect programmers to handle the error (even if that handling is _sometimes_ limited). There could be many reasons why these functions fail depending on the library implementation (or maybe just a localized coding error in the application itself).. so assuming they are always catastrophic reasons is just a narrow viewpoint.
-
While there are certainly some errors that can't be handled well/predictable (e.g. if memory was corrupted by a buffer overrun, then attempting to even show an error dialog may cause yet another error). But I don't think aborting the program should be done just because a thread couldn't be created (since it is generally an initialization error, like opening some required and missing resource file, not corruption making the running image unstable). If it was a problem beyond that (machine hardware or OS failing), then it doesn't really matter what any application does since you are likely going to have to hardboot your system anyway. If I was using some editing application that internally spawns threads to perform certain [user triggered] operations, I don't want it exiting and loosing all my in-memory edits just because it couldn't create a thread to perform an operation that has yet to be run. I'd want an error message so that I have a chance to save my work and possibly restart the program. Worst case is trying to save also fails with another error and I'm out of luck, but otherwise being able to save is a better option. And if the pthread functions failing was really such an unpassable wall, then why would they even return error codes at all and not abort the program for you? It is because they expect programmers to handle the error (even if that handling is _sometimes_ limited). There could be many reasons why these functions fail depending on the library implementation (or maybe just a localized coding error in the application itself).. so assuming they are always catastrophic reasons is just a narrow viewpoint.
I don't think that someone would want to handle the failure of core functions and thread creation is quite a core feature in my opinion. Even if you would want to handle errors after every single line of code you would fail. The solution to your problem is building an automatic document save/backup function into your crash handlers/critical function. This way you guarded your program not only against thread creation errors but a lot of other bugs/crashes too! BTW, in most of my programs I usually create all needed threads at program startup (in pools) and destroy them at cleanup. In this case a CRITICAL is valid even without document saver. Most multithreaded programs work with a fixed or predictable number of threads that you can precreate.
