|
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.
|
|
|
|
|
I still like the ones that you used to see a lot of the form:
description of the problem<br />
Cancel this action?<br />
<br />
[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.
|
|
|
|
|
Just for fun, have a look at this:
http://imagesup.net/?di=213751878365[^]
What is this talk of release? I do not release software. My software escapes leaving a bloody trail of designers and quality assurance people in its wake.
|
|
|
|
|
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..."
|
|
|
|
|
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.)
|
|
|
|
|
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.
|
|
|
|
|
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
|
|
|
|
|
NickPace wrote: Should never get this message.
I prefer "If you see this, there is something terribly wrong."
|
|
|
|
|
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.
|
|
|
|
|
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...
|
|
|
|
|
An even better 'hypothetical' error message:
Monitor not detected. Turn it on to continue.
|
|
|
|
|
A message like that actually exists in the BIOS firmware.  (Actually saw it once. On the monitor. )
brisingr_aerowing@Gryphon-PC $ rake in_the_dough
Raking in the dough
brisingr_aerowing@Gryphon-PC $ make lots_of_money
Making lots_of_money
|
|
|
|
|
+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...
|
|
|
|
|
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
|
|
|
|
|
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. 
|
|
|
|
|
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.
|
|
|
|
|
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...
|
|
|
|
|
At least it gives some indication of something, as opposed to an empty catch block grrrrrrr! 
|
|
|
|
|
Could be worse.. something like (in C):
exit(0);
Now there is a useful error message.. oh, wait! what message? 
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). 
|
|
|
|
|
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.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
