• Obviously (unregistered)

    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.

  • CigarDoug (unregistered) in reply to My name
    My name:
    When a man says something and no woman is there to hear it:

    Is he still wrong?

    Q: How many feminists does it take to change a lightbulb?

    A: That's not funny.

  • (cs) in reply to Zacrath
    Zacrath:
    Perhaps when a tree falls and there is noone to here it, the tree enters a superposition where it is both making a sound and not making a sound.
    Related: Here documents originate in the Unix shell!

    So these documents are papers made from trees and the trees were planted in shells!

  • (cs) in reply to Lorne Kates
    Lorne Kates:
    My name indeed:
    Schrödinger's tree.
    If a cat is caught in a Schrödinger tree and there's no cartoon fireman there to rescue it, does the analogy die?
    Let's leave the koans to Hanzo, shall we?
  • (cs) in reply to ZoomST
    ZoomST:
    I feel that the comment input is behaving strangely today. Does it feels too Mondaysh?

    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.

  • anonymous (unregistered) in reply to Gyxi
    Gyxi:
    Have you ever seen an error message from an app on your iPhone? No, it just closes the application, saying nothing about an error occurring and not letting people know what happened.
    Yes, I've seen them... they're filed under Settings, General, About, Diagnostics & Usage, Diagnostics & Usage Data.
    Gyxi:
    The developer from the story learned that if you don't tell anyone there is an error, then, in the mind of most people, there is no error.
    But you also file the crash report somewhere so that if someone needs to know what went wrong, they can figure out what happened. Right?
  • Calli Arcale (unregistered)

    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.

  • anonymous (unregistered) in reply to Calli Arcale
    Calli Arcale:
    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.

    I pretty quickly learned that Greasemonkey scripts are pretty hard to debug if you don't trap errors, because Greasemonkey silently catches Javascript errors (and by "silently" I mean they don't appear in the web console log). After that, all my scripts were wrapped in
    try {
    // code goes here...
    } catch (e) {
    alert(e.name + ": " + e.message);
    }
    ... and it stays in even when I'm "done" with the script. Of course, if I wanted to deploy a script for use by others, it'd probably make more sense to use a console.log instead of an alert; for my own use, I want to know if it fails, every time it fails, as soon as it fails.

  • (cs) in reply to JimM
    JimM:
    If the appropriate behaviour when an error condition occurs is to ignore it and carry on - and sometimes it is - then that's fair enough. try/catch/do nothing is sometimes the correct decision. But when it's the only error handling in a codebase, someone's probably doing it wrong.
    Precisely. Doing it once, where the error is expected and the correct recovery action is to do nothing, that's no problem. Putting it everywhere though? That's what some of my colleagues have done rather too often in the past… (Don't catch unless you can do The Right Thing with what you've caught. And, if you're going to wrap it and rethrow, don't log it at the same time; you just double the noise in the log at the point where you finally figure out what to do.)
  • moz (unregistered) in reply to Tux "Tuxedo" Penguin
    Tux "Tuxedo" Penguin:
    TRWTF is that TDWTF's idea of "daily" is from monday to friday. Give us WTFs on weekends too!
    Monday to Friday? The slackers took last Thursday off too. I want my mo... Oh.
  • Sergio (unregistered)

    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"); }

  • Andrew Au (unregistered) in reply to Gyxi

    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.

  • Sergio (unregistered) in reply to Andrew Au

    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)

  • anony (unregistered) in reply to RandomGuy
    RandomGuy:
    Obligatory xkcd reference: http://xkcd.com/1188/. @Askimet: How can xkcd be spam?

    This came more to my mind: http://geekandpoke.typepad.com/geekandpoke/2009/06/simply-explained-checked-exceptions.html NO SPAM

  • Chad Garrett (unregistered) in reply to Tux "Tuxedo" Penguin
    Tux "Tuxedo" Penguin:
    TRWTF is that TDWTF's idea of "daily" is from monday to friday. Give us WTFs on weekends too!

    T...D...W...T...F

    Tuesday, Durdlesday, Wednesday, Thursday, Friday.

    TRWTF is having stories on Monday and Durdlesday not existing.

  • Drone-1 (unregistered) in reply to Mike

    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

  • ToErrIsHumanToReallyFoulThingsUpRequiresAComputer (unregistered)

    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.

  • (cs) in reply to Drone-1
    Drone-1:
    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.
    Typically, those sorts of failures would be Errors, which are not exceptions in Java. Just sayin'
  • S (unregistered) in reply to TheCPUWizard
    TheCPUWizard:
    If you can't "fix" it, then DONT catch it. LEave it up to the caller. If the caller cant fix it, then let the application terminate. SIMPLE.

    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.

  • S (unregistered) in reply to Sergio
    Sergio:
    and Spring exception handling used like this:

    @ExceptionHandler(Exception.class) public void exception() { logger.error("there was an error"); }

    You're doing well. The code I usually see would be:

    logger.debug("there was an error");

    That is, something goes badly wrong, but the developer didn't feel the need to tell anyone unless they turned on full verbose debugging...

  • Error Checking Developer (unregistered)

    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.

  • (cs) in reply to ANON
    ANON:
    Hm, my code often looks the same. I mean how should I catch an IOException if I want to write to a FileOutputStream? Write to an error log instead? If the the hard drive is out of space that won't help either.

    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.

  • (cs)

    If at first you don't succeed...just pretend it never happened.

  • I always lie (unregistered) in reply to Zacrath
    Zacrath:
    Balu:
    Zacrath:
    Does a tree make a sound if it falls in the woods and there's nobody there to hear it?
    Yes

    "Sound is a sequence of waves of pressure that propagates through compressible media such as air or water."

    A tree will cause those waves whether or not there is an ear to hear them.

    Have you measured it? Who can prove that sound waves are actually generated while nobody is there to hear (= measure) them?
    Perhaps when a tree falls and there is noone to here it, the tree enters a superposition where it is both making a sound and not making a sound.

    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.

  • Duc (unregistered) in reply to Passing by

    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 } }

  • QJo (unregistered) in reply to S
    S:
    Sergio:
    and Spring exception handling used like this:

    @ExceptionHandler(Exception.class) public void exception() { logger.error("there was an error"); }

    You're doing well. The code I usually see would be:

    logger.debug("there was an error");

    That is, something goes badly wrong, but the developer didn't feel the need to tell anyone unless they turned on full verbose debugging...

    Ours was the program that terminated:

    oh bugger
    
  • Meep (unregistered) in reply to Gyxi
    Gyxi:
    Have you ever seen an error message from an app on your iPhone? No, it just closes the application, saying nothing about an error occurring and not letting people know what happened. Users will just press re-open and try again and if it works the 2nd time around, they are usually quite happy.

    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.

    The developer from the story learned that if you don't tell anyone there is an error, then, in the mind of most people, there is no error.

    People don't think in terms of errors or exceptions. They think in terms of whether they accomplished what they set out to do.

  • John Max (unregistered)

    "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

  • Meep (unregistered)
    It was the Java version of On Error Resume Next; it beat every error into silent submission.

    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:

    try {
       foo();
    } catch(Error e) {
    }

    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?

  • Norman Diamond (unregistered) in reply to faoileag
    faoileag:
    Take pthread_mutex_init(...). The function returns 0 if successful and a value if not (at least on QNX).

    I've seen embedded code that relied on mutexes but not even once checked the return value of pthread_mutex_init().

    So, if creating the mutex failed, the program ploughed on regardless. Ignoring a mutex condition in a multithreaded application can get you into all sorts of trouble but the main reaction was a shoulder shrugging "so what?". Even when we developed a demo demonstrating a deadlock it didn't help.

    That was really sad to watch.

    You. Front page. Now.

  • Norman Diamond (unregistered) in reply to faoileag
    faoileag:
    It is a bad experience for the user, yes. But probably a far better experience then the sense of false security created by dropping the exception.

    Think backups. If

    cp foo.txt <some_path>/foo.txt
    would silently ignore all write problems to <some_path>, I would think the back exists, when in reality there is nothing.
    No kidding. And people wonder why I complained about Windows 95.

  • Bill C. (unregistered)
    Monica:
    Exceptionally Hard to Swallow
    That's what she said.
  • (cs)

    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.

  • (cs) in reply to CigarDoug
    CigarDoug:
    My name:
    When a man says something and no woman is there to hear it:

    Is he still wrong?

    Q: How many feminists does it take to change a lightbulb?

    A: That's not funny.

    sigh

  • Dartmoor C (unregistered) in reply to Passing by
    Passing by:
    Gyxi:
    Have you ever seen an error message from an app on your iPhone?

    But in multiuser application, managing critical data, I am sure SOME (if not MOST of the errors) could be fixed by the user, or at least the user shoudl get meaningful information

    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'.

  • Ryan (unregistered)

    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

  • Richard (unregistered)

    The original programmer where optimists.

  • nasch (unregistered) in reply to Meep
    Meep:
    It was the Java version of On Error Resume Next; it beat every error into silent submission.

    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:

    try {
       foo();
    } catch(Error e) {
    }

    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?

    It said it beat "every error" into submission. Not "every Error". Is capitalization really than hard to comprehend?

  • MaxDZ8 (unregistered)

    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.

  • Jason (unregistered) in reply to Passing by

    I'm a (sometimes) Android developer, and my typical response to application errors is LOGCAT TO THE FACE!!!

  • (cs) in reply to Meep
    Meep:
    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?
    Ask this question the inventors of the Java language, who made (the unchecked) RuntimeException a subclass of the (checked) Exception class.
  • RFoxmich (unregistered)

    Regarding error handling see:

    http://www.multicians.org/unix.html

    and what Dennis Ritchie said about it.

  • Neil (unregistered)

    This is my take on the anti-pattern:

    void ProbablyDoSomething() {   try {     MaybeDoSomething();   } finally {     return;   } }

  • OptimizeWTF (unregistered) in reply to Gyxi

    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.

  • (cs) in reply to Neil
    Neil:
    This is my take on the anti-pattern:

    void ProbablyDoSomething() {   try {     MaybeDoSomething();   } finally {     return;   } }

    Does that work in Java? I know that it wouldn't even compile in .NET.

  • Martin (unregistered) in reply to Gyxi
    Gyxi:
    The developer from the story learned that if you don't tell anyone there is an error, then, in the mind of most people, there is no error.

    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.

  • (cs) in reply to Martin
    Martin:
    Gyxi:
    The developer from the story learned that if you don't tell anyone there is an error, then, in the mind of most people, there is no error.

    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.

    You've never had anything shipped to you, have you?

  • Norman Diamond (unregistered) in reply to RFoxmich
    RFoxmich:
    Regarding error handling see: [url]http://www.multicians.org/unix.html[/usr] and what Dennis Ritchie said about it.
    Tom Van Vleck:
    We went to lunch afterward, and I remarked to Dennis that easily half the code I was writing in Multics was error recovery code. He said, "We left all that stuff out. If there's an error, we have this routine called panic, and when it is called, the machine crashes, and you holler down the hall, 'Hey, reboot it.'"
    I guess that explains why Unix quality used to be what it was. I was editing a file of around 1000 lines, typed a w command (which would be :w in vi or vim), waited for Unix to come back up, and ... my file didn't exist any more. The old version wasn't there, the new version wasn't there, it was gone.

    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.

  • Muphry (unregistered) in reply to Norman Diamond
    Norman Diamond:
    [/usr]
    You even hit the "preview" button but then submitted it anyway. Twit.
  • Captain Troll (unregistered) in reply to Lord0

    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?

Leave a comment on “Exceptionally Hard to Swallow”

Log In or post as a guest

Replying to comment #:

« Return to Article