- Feature Articles
- CodeSOD
- Error'd
- Forums
-
Other Articles
- Random Article
- Other Series
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
Once all clients who might be listening for falling trees are far enough away from the chunk of terrain which contains the tree in question, that chunk will no longer be simulated at the required level of detail, and the tree should either be destroyed or get garbage collected along with all the other stuff in the chunk.
Presumably then, the falling never actually occurs BECAUSE there are no observing clients.
The question that IS interesting, is when observers return to proximity to that chunk of terrain, will the tree be re-generated in the expected "fallen" state, and will an echo be retrospectively generated with all appropriate reverb and attenuation calculated correctly?
I don't mind if it doesn't cause a sound at the time, so long as a returning observer is given a coherent illusion of consistency.
Admin
A: That's not funny.
Admin
So these documents are papers made from trees and the trees were planted in shells!
Admin
Admin
Sounds like somebody's got a case of the Mo --
The second worst forum commenting in the Universe is that of the Azgoths of Kria. During a posting by their forum master Grunthos the Flatulent of his poem "Ode to a Small Lump of Green Putty I Found in My Armpit One Midsummer Morning" four of his audience died of internal haemorrhaging and the president of the Mid-Galactic Arts Nobbling Council survived by gnawing one of his own legs off. Grunthos was reported to have been "disappointed" by the poem's reception, and was about to embark on the eighteen thousandth quoting of "Office Space" on The Daily WTF message board when his own major intestine, in a desperate attempt to save humanity, leapt straight up through his neck and throttled his brain.
Admin
Admin
I used to do exactly that.
However, I quickly learned my lesson and stopped doing that. ;-) It's a very bad habit. I used to justify it with "well, this shouldn't fail" or "well, this is a throwaway application, I just need to get it done". Then I realized the stupidity of both of those justifications. It's not hard to do some very basic error checking, and if you don't take the tiny amount of time needed to do something with the exception (whether that's passing it on up or handling it right here), you're going to spend more time than that later on dealing with the mysterious faults that you can't figure out because you've silently trapped all the exceptions.
Admin
Admin
Admin
Admin
I've seen 2 examples of this that caused my panic:
try { ... 300 lines of code calling other 30 methods and services ... } catch (Exception e) { //TODO Auto-generated catch block }
and Spring exception handling used like this:
@ExceptionHandler(Exception.class) public void exception() { logger.error("there was an error"); }
Admin
Not that I am happy with the swallow all everywhere practice, but, sometimes, fail-fast is the right way to deal with problems.
If there are issue you don't know how to recover (or just don't bother to so to keep the system simple), then just crash the server and let a new instance stand up (or fail-over automatically to a hot-standby).
That reduces complexity a lot and you sure complexity breed bugs.
Admin
if you don't do anything, you will never know there was a problem. You should at least log the error somewhere, and 90% of the times you want to tell the app user something went wrong (except for batch processes or coding horrors generated errors)
Admin
This came more to my mind: http://geekandpoke.typepad.com/geekandpoke/2009/06/simply-explained-checked-exceptions.html NO SPAM
Admin
T...D...W...T...F
Tuesday, Durdlesday, Wednesday, Thursday, Friday.
TRWTF is having stories on Monday and Durdlesday not existing.
Admin
Another reason not to do catch(Exception e) is because it makes it easier for someone to maliciously tamper with the state of the program without it crashing.
If you know that a piece of code is going to throw an Exception, and you know the Exception is no big deal, then catch only that specific exception, and add a descriptive comment about why you're doing it for other devs to see.
Captcha: eros, catching all exceptions and eros is overkill
Admin
Ahh, the good ol' error hiding anti-pattern:
http://en.wikipedia.org/wiki/Error_hiding
I used to display meaningful errors in my applications until my boss told me to just display "there was an error your Internet connection sucks" (paraphrased slightly) whenever an error occurred even though I tried to explain the error hiding anti-pattern to him.
Admin
Admin
The problem is, it's Java, and Java has checked exceptions which it uses heavily in core APIs. So if some piece of code hypothetically throws an IOException, you can't just leave it - you have to either catch it, or have the calling code declare that it throws IOException, and so on up to the top of the stack, through code that has nothing to do with IO.
Except that sooner or later, you'll be in a method that implements an interface that doesn't permit that declaration, so you'll have to catch it there, like it or not.
Admin
That is, something goes badly wrong, but the developer didn't feel the need to tell anyone unless they turned on full verbose debugging...
Admin
I normally code in such a way that there are no blatant errors and no error messages shown to the user. Every error writes to a specific text file depending upon where the error occurred. Also as long as the error is not fatal operation continues. This makes errors very easy to debug while not bothering users. The problem with the error handling method presented in this article is: "If no developer knows about an error, but every user knows the program occasionally randomly crashes, can anyone fix the error that is causing the crash?" The obvious answer is NO.
Admin
It depends on what your environment is. If you're working on a client application, such as a .NET Windows app, the user should know about this error, since they can do something about it.
But if it's something like a .NET web app, the users should be told that something is wrong, and the app and/or functionality is unavailable. Then flood the sysadmin with info in log files, database entries, emails, etc.
Admin
If at first you don't succeed...just pretend it never happened.
Admin
The tree is in a superposition of having fallen and not fallen until observed. If it's observed to have fallen, it made a sound when it fell.
Admin
Of course, there are tests. The test coverage is one of the highest close to 100% of all measure available. And all the test are alike
void testSomething() { try { //execute some code } catch (Exception ex) { //pass anyway } }
Admin
Ours was the program that terminated:
Admin
If people lose what they were working on, they're not going to be pleased.
But if they're right back to where they were after a crash, you've ensured that they could resolve the problem.
What mobile app designers have done is ensure that their process can be stopped and started easily, whereas the tradition with desktop apps is you have to start from scratch each time and put up with minute long load times.
People don't think in terms of errors or exceptions. They think in terms of whether they accomplished what they set out to do.
Admin
"and so became the standard against which all other code was measured."
this sentence really sounds fake and exaggerating.
go and play with your little dolls, wannabe-programmer little girl
i am expecting some high level quality IT WTF here
Admin
I realize no one here can code their way out of a wet paper bag, but that example is guaranteed to not catch a single error. To catch errors, you have to use:
An Exception ISA Throwable, and an Error ISA Throwable, that doesn't mean that Errors are Exceptions or vice versa. Is single-inheritance really that hard to comprehend?
Admin
Admin
Admin
Admin
So to sum up the comments section:
We have a surprising number of people who believe that this code is acceptable.
A silly conversation about whether a tree makes a noise when it falls that somehow transformed into a reference to Schrödinger's cat.
And an immature "That's what she said" joke.
Admin
sigh
Admin
But in a multi-user application, which user do you send the information to? Why would you think that a particular error would be meaningful to a particular user?
It's in situations like that, where the system should be able to report errors without collapsing all users, where a system-supported version of 'on error resume next' allows you to correct and report exceptions without having to build your own version of 'on error resume next'.
Admin
It wouldn't throw exceptions, but it would still throw errors - of they really wanted to do this bad code well they'd catch throwable
Admin
The original programmer where optimists.
Admin
It said it beat "every error" into submission. Not "every Error". Is capitalization really than hard to comprehend?
Admin
It recalls me of a job I had some months ago. There was a component marketed as LEADS (what a coincidence!) which my employer bought from an US-based company declaring decades of experience in safety-critical equipment. It spurred out all kinds of odd data. Besides being extremely inefficient it would often cause the server application to hang, most of the time restarting it would require a full reboot.
Admin
I'm a (sometimes) Android developer, and my typical response to application errors is LOGCAT TO THE FACE!!!
Admin
Admin
Regarding error handling see:
http://www.multicians.org/unix.html
and what Dennis Ritchie said about it.
Admin
This is my take on the anti-pattern:
void ProbablyDoSomething() { try { MaybeDoSomething(); } finally { return; } }
Admin
Fair enough, the user doesn't need to know the error occurred, but someone should know, something should log the usecase. This information is very useful for maintenance teams, support and devs tasked to fix seemingly 'perfect code'.
try { // do something } catch { // do nothing }
is the worst pattern. Period (meta). I would fire someone from my team if they produced this code, unless they had a really really really good reason, and even then they would be on their last warning.
Admin
Does that work in Java? I know that it wouldn't even compile in .NET.
Admin
This is actually a massive cultural error. We have all been taught "this is how computers work". Were things like this to happen in almost any other aspect of people's lives they would get fixed very quickly. Imagine almost any other part of your life and imagine this situation happening. You flush your toilet and walk away, come back later there's still a big turd in it. How long till you call the plumber or visit Home Depot? Or, your house door simply doesn't lock. How long till a locksmith is on the way? Or your car randomly stops running, but turn the key and off you go again. How long till it was in the shop?
No. This isn't an issue where errors can be hidden. It's that we've come to accept that all software will be horribly buggy and meh, just live with it. We've gotten over that in just about every other part of our lives.
Admin
You've never had anything shipped to you, have you?
Admin
When people started using Unix for stuff like database systems, I used to wonder WTF?
But Unix gradually improved.
Then Windows 95 came along and it was just like old times, only worse.
I wouldn't have guessed that dmr was to blame for it. It was saddening to read that.
Admin
Admin
No, but an app filled with those empty catches, that was supposedly free of bugs and programmed by a team who had a supposedly legend among them is worth a story these days
Isn't it supposedly obvious?