The Daily WTF: Curious Perversions in Information Technology

2013-12-02 Reply Admin

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.

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.

2013-12-02 Reply Admin

Exception in thread "main" com.thedailywtf.CommentNotFoundException at com.thedailywtf.newComment(Frist.java:7714)

2013-12-02 Reply Admin

Try ( // Some Comment here }

Catch ( Post.anyway )

2013-12-02 Reply Admin

Obligatory xkcd reference: http://xkcd.com/1188/. @Askimet: How can xkcd be spam?

2013-12-02 Reply Admin

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

I understand that in a restricted environment designed basically for fun, like a mobile device, where the user has few or no option at all to fix an error, just crashing might (in some twites way) the "right" way to go. And I have seen it in Android apps too (too often, I mean), so it is not an iOS characteristic. 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 so the error can be reported to the people responsible for the app. But the lesson is, indeed, that if people see nothing they think there's nothing. I just wonder what kind of team manager let's code like this go into production. SHouldn't someone read anty piece of code to check that it is doing the things ity is supposed to do in a responsible way? Aren't there tests to check that code behaves properly when things go worng?

2013-12-02 Reply Admin

In PHP this whole construction can be written in one character: @

Zacrath · 2013-12-02 Reply Admin

I guess she just wanted the program to follow the advice her mother gave her: If you don't have anything nice to say, don't say anything at all.

2013-12-02 Reply Admin

Does a tree make a sound if it falls in the woods and there's nobody there to hear it?

I HEAR ALL!

Zacrath · 2013-12-02 Reply Admin

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.

2013-12-02 Reply Admin

Passing by:
I understand that in a restricted environment designed basically for fun, like a mobile device, where the user has few or no option at all to fix an error, just crashing might (in some twites way) the "right" way to go.

Actually, the point is, that the WTF code displayed would NOT crash. It would just behave undefined (which is a lot worse than crashing).

The point of exception handling is:

If an error happens, notify the affected caller
Caller can try to fix the error
If the caller doesn't fix the error, the application is deemed to be in an "unfixable" state in which case a "crash" (e.g. forced close with error message and/or log data) is the correct thing to do. --> continue working with an application that is in an unknown state can lead to strange results/error later on. So better fail fast at the point where you know WHY you fail.

ObiWayneKenobi · 2013-12-02 Reply Admin

The worst part is the mentality that managers have that if no errors are being reported, there are no errors; that's what empowers nonsense like this. Just swallow all exceptions and your code has zero bugs.

pure · 2013-12-02 Reply Admin

Like 99% of CodeSODs, TRWTF is not doing code reviews.

2013-12-02 Reply Admin

Shinobu:
In PHP this whole construction can be written in one character: @

This is wrong. Learn the difference between errors and exceptions, then try again.

2013-12-02 Reply Admin

B. M.'s coworker was the stuff of which legends are made;

Nice to know that, but what does he have to do with the rest of the story ?

2013-12-02 Reply Admin

So

} catch (Exception e) { // do nothing }

Is worth a story these days? Really?

2013-12-02 Reply Admin

Nothing exceptional to see here ...

2013-12-02 Reply Admin

So the benchmark that all code was measured against was never itself measured? Seems like neither was all the other code then.

2013-12-02 Reply Admin

guestimate:
B. M.'s coworker was the stuff of which legends are made;
Nice to know that, but what does he have to do with the rest of the story ?

Try quoting the full paragraph:

B. M.'s coworker was the stuff of which legends are made; code was always delivered ahead of schedule and it never threw an error. Her code was the least buggy in the entire department, and so became the standard against which all other code was measured.

The coworker referred to (she, not he, by the way) wrote the code that the rest of the story describes.

2013-12-02 Reply Admin

TRWTF is that TDWTF's idea of "daily" is from monday to friday. Give us WTFs on weekends too!

2013-12-02 Reply Admin

once told my manager to gtfo and dodged working on similarly written application.

i'm fine with badly written code, but this kind of data integrity with ~3 year historical untraceable semi-random changelog scares me away like nothing else. it's not just hard to understand that kind of code - it's close to impossible unless you are given infinite amount of time and even then there will be left grey areas you ain't really sure about. not to mention "small" issues like bunch of half-dead threads for managing web portal user sessions (Asp.net has inbuilt stuff for that), db queries that deletes data, fact that every post to server updates ~2000 db rows no matter what's the intention. also: iframes!!11eleven

you know how redirects were made? by sending response:

String.Format("<script type='text/javascript'>
 window.location = '{0}';
</script>", url)

with new Chrome update application stopped working because of security issues and 'Works best on Internet Explorer 6' was born.

2013-12-02 Reply Admin

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.

TheCPUWizard · 2013-12-02 Reply Admin

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.

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.

2013-12-02 Reply Admin

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?

2013-12-02 Reply Admin

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?

Actually, you could well argue that if you are measuring them, in a way you are there. It's probably quantum.

2013-12-02 Reply Admin

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.

+1e11. That.

Zacrath · 2013-12-02 Reply Admin

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.

2013-12-02 Reply Admin

Pokémon-style exception handling! Gotta catch 'em all!

2013-12-02 Reply Admin

TheCPUWizard:
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.

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.

Obviously not so simple as this pattern occurs quite often.

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.

2013-12-02 Reply Admin

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.[/quote]

This is the correct answer from a dev. This is bad program behaviour for a user. (app went boom)

Now, are we writing apps for the devs or the users?

2013-12-02 Reply Admin

TheCPUWizard:
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.

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.

But not every exception is relevant enough for the program to terminate. It might still do useful things even if it fails to write a file.

2013-12-02 Reply Admin

[quote user="Mike"]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.[/quote]

This is the correct answer from a dev. This is bad program behaviour for a user. (app went boom)

Now, are we writing apps for the devs or the users?[/quote]For the bosses, indeed.

2013-12-02 Reply Admin

Tux "Tuxedo" Penguin:
TRWTF is that TDWTF's idea of "daily" is from monday to friday. Give us WTFs on weekends too!

The quality would probably go down if there were more WTFs, seems good to have it like this. On a related note I though they had taken seriously the comments like "If you don't have anything good to post, skip a day" on Thursday, but it turns out it was Thanksgiving or some such.

2013-12-02 Reply Admin

[quote user="ZoomST"]

[quote user="Mike"]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.[/quote]

This is the correct answer from a dev.
This is bad program behaviour for a user. (app went boom)

Now, are we writing apps for the devs or the users?[/quote]For the bosses, indeed.

[/quote] Oops! Seems like Quote button is not giving the first part of the quote. My bad for not using Preview today. I feel that the comment input is behaving strangely today. Does it feels too Mondaysh?

2013-12-02 Reply Admin

I've had to deal with the following even worse construct through half a dozen different languages over the years.

IF FunctioningReturningNegativeErrorCodes < 0 THEN ANSWER -1;

Don't do nothing, make sure the rest of the software knows something went wrong but make damn sure you discard what it was.

2013-12-02 Reply Admin

ANON:
TheCPUWizard:
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.

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.

But not every exception is relevant enough for the program to terminate. It might still do useful things even if it fails to write a file.

Then you've answered the question of "fixing" it already. In that scenario it's perfectly legitimate to ignore the exception, that is the way you fix it.

I suspect however that being unable to write to the filesystem is more likely to be something you're unable to just ignore.

2013-12-02 Reply Admin

Mike:
Now, are we writing apps for the devs or the users?

For the users - the people who are likely to get very pissed off when your application gives them the impression it successfully wrote to a file/database but in reality silently swallowed an exception and continued on in an undetermined state.

If there was a rolling eyes smiley, it would be right here -> .

2013-12-02 Reply Admin

Mike:
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.

This is the correct answer from a dev. This is bad program behaviour for a user. (app went boom)

Now, are we writing apps for the devs or the users?

For the user. That's why TheCPUWizard put the instruction "Leave it up to the caller" into his recipe.

If a function deep in some library throws an exception, that function usually is in no position to decide how that circumstance should be handled.

So the exception bubbles up. At some point, it should reach a function that does know how to handle such a situation. And if that just means displaying a dialogue saying that something could not be done.

If the developer of the application fails to provide that sort of exception handling then he or she should be blamed for not adequately handling the situation.

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.

(Ok, bad example, I know that backups are mythical things like mermaids)

JimM · 2013-12-02 Reply Admin

Mike:
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.

This is bad program behaviour for a user. (app went boom)

You appear to be confusing "caller" with "user". If a user is knowingly issuing the call to a function in the application, there's something more seriously wrong with your application than the error handling :p

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.

2013-12-02 Reply Admin

When a man says something and no woman is there to hear it:

Is he still wrong?

pjt33 · 2013-12-02 Reply Admin

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 hard drive is out of space that won't help either.

Most IOExceptions probably aren't due to running out of disk space but to lack of permissions.

2013-12-02 Reply Admin

Lord0:
So
} catch (Exception e) { // do nothing }

Is worth a story these days? Really?

It's not just that the exceptions were caught and swallowed. TRWTF was that this worker's code was deemed exceptionally (no pun intended) good purely because it didn't throw exceptions -- because of the above antipattern.

So what happened is that a very bad programmer had a reputation for being a very good programmer. In my mind this is the bedrock of TDWTF: the Dunning-Kruger effect writ large and projected.

2013-12-02 Reply Admin

I like On Error Resume Next.

2013-12-02 Reply Admin

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.

Schrödinger's tree.

2013-12-02 Reply Admin

[quote user="Mike"]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.[/quote]

This is the correct answer from a dev. This is bad program behaviour for a user. (app went boom)

Now, are we writing apps for the devs or the users?[/quote]

We write them for the users. a) I as a user don't like it if my App tells me "Hey, there is an error in <enter error description here>. I can't fix it, so I crashed". BUT I definitely like it even less if my App DOESN'T tell that it encountered a serious error and cannot continue anymore. Then still let me continue and in the end leaves me with:

Mangled files (oops... we just wrote some incorrect and illegible data on top of your valid data... sorry about that...)
Lost data (You wanted to save this data? Well I could have told you an hour ago that this wasn't possible...)
Lost data, second run (This data doesn't exist! Maybe you tried to write it last time and I didn't tell you that we failed. But at least you thought you had the data. That counts as well... doesn't it?)
Random application crashes (Unitialized window/thread/process handle? So what... we'll use it anyway. If any other application actually uses this handle. Bad luck, but not my problem)
Incorrect Behavior (You now pressed this button multiple times. I could tell you that the action fails. It will certainly also fail the next 10 times because of <enter reason here>. But I'm not telling you!!)

Captcha: erat (humanum est)... somehow this fits

ObiWayneKenobi · 2013-12-02 Reply Admin

pure:
Like 99% of CodeSODs, TRWTF is not doing code reviews.

TRWTF is that most places have no idea what a code review entails, why it's a good thing, or why they should bother with them.

Lorne Kates · 2013-12-02 Reply Admin

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?

2013-12-02 Reply Admin

Context is everything

Of course fail silent isn't acceptible, but neither letting the app go boom which was what my original response ws to.

Just because you can't solve the original exception does not mean that you give up and throw the mess in the users face. You still have to handle it and give users an informed choice, or even ignore it if it is clearly a non-fatal. Otherwise we are back to "and error occured, tough shit, you lose kthanksbye"

2013-12-02 Reply Admin

ZoomST:
Oops! Seems like Quote button is not giving the first part of the quote. My bad for not using Preview today. I feel that the comment input is behaving strangely today. Does it feels too Mondaysh?

Obviously BBCode needs [try] and [catch] tags to handle broken quote tags.

2013-12-02 Reply Admin

Even if you don't the user to see errors, you should at least be logging them and someone should be looking at them when they do occur. Serious failures should stop production

I once inherited a server app that was old and crusty and seemed to run really slowly and data would simply disappear or it would simply stop responding. This was a critical app that needed to be up 24/7. I found the entire code base riddled with empty catch blocks and a master catch block just in case something got missed. The previous manager had mandated this coding practice and prohibited logging of any kind. The first thing I did was add logging to every catch block. It was then I learned how badly the code behaved. Sure, it met the criteria of being up 24/7, but it would spend hours and sometimes even days or weeks doing nothing because it would get stuck in a bad state after swallowing an exception. It would take a technician to examine its output or a customer complaining that they didn't have data for the last few weeks before someone would reboot the system. It never crashed, though! I changed that by making sure critical errors brought down the system so that technicians would be forced to address the problem and we could code a fix. I spent a YEAR chasing all the bugs while begging my manager for the chance to do a rewrite. I finally left that place and wonder what poor sod is going to inherit that mess and blame me for it.

2013-12-02 Reply Admin

Passing by:
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.
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.

I understand that in a restricted environment designed basically for fun, like a mobile device, where the user has few or no option at all to fix an error, just crashing might (in some twites way) the "right" way to go. And I have seen it in Android apps too (too often, I mean), so it is not an iOS characteristic. 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 so the error can be reported to the people responsible for the app. But the lesson is, indeed, that if people see nothing they think there's nothing. I just wonder what kind of team manager let's code like this go into production. SHouldn't someone read anty piece of code to check that it is doing the things ity is supposed to do in a responsible way? Aren't there tests to check that code behaves properly when things go worng?

Somebody put this person on the writing staff!

Exceptionally Hard to Swallow

Leave a comment on “Exceptionally Hard to Swallow”