The Daily WTF: Curious Perversions in Information Technology

2014-06-09 Reply Admin

There's the new kid on the block named "Swift".

Exception handling in Swift: There isn't any. There aren't any exceptions. Ok, there are conditions that will kill your code immediately, but there are no exceptions that you could catch in Swift code.

That's a huge improvement to Objective-C, where the occasional .net or Java programmer would start throwing and catching exceptions all over the place (until they were told to stop it).

2014-06-09 Reply Admin

I suspect their entire exception handling pattern was deeply flawed to begin with.

So this young neophyte was stuck in a Big Ball of Mud with no guidance. You can't blame him for trying to find his way out.

2014-06-09 Reply Admin

Shakespere or something:
Those who don't know recursion are doomed to repeat it.

Once saw a screen-field navigation solution in which each field was responsible for finding the next field. They would set a variable saying they were looked at, then clear it on the way out of the call stack. That way if it looped around and a control saw the next control had the flag set, it would know that there is no field to navigate to and stop.

So, when a field was called, if it couldn't take focus, it would call the next field. This meant that ever field was on the stack (recursively).

If a field was the last in a container, it would call the container to get the next container, adding another call onto the stack.

Unfortunately, this didn't have good exception handling, so fields would get their "I was looked at" flag stuck on, and never receive focus again.

Of course, it had other issues.

It supported arrow key navigation. It calculated a box in that direction using infinite (width/height) and the width/height of the starting control, and recursively visited fields within that box in that direction.

...

Needless to say, it failed so hard, in so many ways.

Matt Westwood · 2014-06-09 Reply Admin

dkf:
Needs more polymorphism, so we could go…
Logger logger logger logger logger chameleon, You throw and fail, You throw and faaaaaaail…

Good oh. That was my immediate reaction as well.

2014-06-09 Reply Admin

A Guy:
How can you type 'ExceptionLoggerLoggerLoggerLogger' without feeling stupid??
And why did he stop at 4?

I'm amazed he didn't try recursion...

Nagesh · 2014-06-09 Reply Admin

OldCoder:
A Guy:
How can you type 'ExceptionLoggerLoggerLoggerLogger' without feeling stupid??
And why did he stop at 4?
I'm amazed he didn't try recursion...

If he did not understand logging, what is it you're thinking that he will understand recursion?

Coyne · 2014-06-09 Reply Admin

That last is such an anti-pattern. This would be much better because it at least guarantees to log something:

myRoutine()
{
   Exception hold;
   trySomething();
   if (something == null) hold = new Exception("blah blah");
   while (true) {
       try {
          log(hold);
          break; 
      } catch (Exception e) { hold = e; }
   } 
}

:-P

2014-06-09 Reply Admin

If it log don't work, log harder!

herby · 2014-06-09 Reply Admin

Look, if the error logger fails, you are on your own!

Or, if you are up to your ass in alligators, you kinda forget that the original objective was to drain the swamp.

2014-06-09 Reply Admin

Nagesh:
OldCoder:
A Guy:
How can you type 'ExceptionLoggerLoggerLoggerLogger' without feeling stupid??
And why did he stop at 4?
I'm amazed he didn't try recursion...

If he did not understand logging, what is it you're thinking that he will understand recursion?

Pity me, I work with someone who actually *DOES* think this is recursion. He did something very similar to this a few months ago, nested three-deep for checking parent-child relationships. It literally never occurred to him that a user would/could keep adding more layers of "parent" on top.... even though he wrote the "parent" code. *smh*

Coyne · 2014-06-09 Reply Admin

anonymous:
If it log don't work, log harder!

Didn't think of that:

   try
   {
       log.write(message);
   }  catch (Exception e) {
       log.writeHarder(message);
   }

2014-06-09 Reply Admin

Mike R.:
The other extreme: Around here a lot of people just do this:
try { ..... } catch ex { }

When you ask, the most common answer is: "I don't want the application to crash."

But, we're trying to make our computers more human! Something goes wrong... "Meh. I'll worry about it later. Maybe. I really just want to get this done and go back to youtube."

2014-06-09 Reply Admin

Log log log your fail gently down the stack. logger logger logger logger Mushroom mushroom snake ;-)

2014-06-09 Reply Admin

Chelloveck:
ben:
sorry, but its turtles all the way down!
That was implied; yes stopping at depth 4 is just lame.

The right way to do it, of course, is with a recursive logging method that will call itself again when an exception is thrown. Then you're sure that the system will do everything it possibly can to get that error message out.

And if the problem persists, at least someone will notice and eventually the issue will get some attention.

2014-06-09 Reply Admin

Bill:
Mike R.:
The other extreme: Around here a lot of people just do this:
try { ..... } catch ex { }

When you ask, the most common answer is: "I don't want the application to crash."
But, we're trying to make our computers more human! Something goes wrong... "Meh. I'll worry about it later. Maybe. I really just want to get this done and go back to youtube."

Nothing will instill rage in a seasoned developer like tracking down an inexplicable problem and finding, at the core of it, an empty catch block. Even if there's nothing to do there you should at least log it, and if it's something that's expected and may happen often then A) You're doing it wrong and B) At least debug log it so it's obvious while you're building the system but doesn't fill up the production logs.

On the Scala project I'm working on now using exceptions and try/catch blocks is considered poor form and I'm finding it rather nice.

2014-06-09 Reply Admin

foo AKA fooo:
Caffeine:
Reminds me of the trace buster buster buster
https://www.youtube.com/watch?v=Iw3G80bplTg&feature=kp
Or the truck truck truck: http://www.youtube.com/watch?v=XVC8Jpb1PrA

Or maybe even http://en.wikipedia.org/wiki/Buffalo_buffalo_Buffalo_buffalo_buffalo_buffalo_Buffalo_buffalo]Buffalo buffalo Buffalo buffalo buffalo buffalo Buffalo buffalo.

Stupid Akismet!

chubertdev · 2014-06-09 Reply Admin

Easy fix:

    void Application_Error(object sender, EventArgs e) 
    { 
        Server.ClearError();
    }

2014-06-09 Reply Admin

odio:
Pity me, I work with someone who actually *DOES* think this is recursion. He did something very similar to this a few months ago, nested three-deep for checking parent-child relationships. It literally never occurred to him that a user would/could keep adding more layers of "parent" on top.... even though he wrote the "parent" code. *smh*

3 levels of parents should be enough for everyone.

2014-06-09 Reply Admin

Valued Service:
Once saw a screen-field navigation solution in which each field was responsible for finding the next field. They would set a variable saying they were looked at, then clear it on the way out of the call stack. That way if it looped around and a control saw the next control had the flag set, it would know that there is no field to navigate to and stop.
So, when a field was called, if it couldn't take focus, it would call the next field. This meant that ever field was on the stack (recursively).

If a field was the last in a container, it would call the container to get the next container, adding another call onto the stack.

Unfortunately, this didn't have good exception handling, so fields would get their "I was looked at" flag stuck on, and never receive focus again.

Yeah, should have handled the flag as RAII or such. See, good patterns can even fix bad code.

It supported arrow key navigation. It calculated a box in that direction using infinite (width/height) and the width/height of the starting control, and recursively visited fields within that box in that direction.

So if a wide field is on top of a narrow one, you can get to the lower one with arrow-down, but not back to the upper one with arrow-up? Brillant!

2014-06-09 Reply Admin

Zylon:
Clearly the guy who wrote this always wanted to be a lumberjack.
And that's okay.

THIS! Do we vote for best post?

2014-06-09 Reply Admin

foo AKA fooo:
Valued Service:
Once saw a screen-field navigation solution in which each field was responsible for finding the next field. They would set a variable saying they were looked at, then clear it on the way out of the call stack. That way if it looped around and a control saw the next control had the flag set, it would know that there is no field to navigate to and stop.
So, when a field was called, if it couldn't take focus, it would call the next field. This meant that ever field was on the stack (recursively).

If a field was the last in a container, it would call the container to get the next container, adding another call onto the stack.

Unfortunately, this didn't have good exception handling, so fields would get their "I was looked at" flag stuck on, and never receive focus again.
Yeah, should have handled the flag as RAII or such. See, good patterns can even fix bad code.

It supported arrow key navigation. It calculated a box in that direction using infinite (width/height) and the width/height of the starting control, and recursively visited fields within that box in that direction.
So if a wide field is on top of a narrow one, you can get to the lower one with arrow-down, but not back to the upper one with arrow-up? Brillant!

Has anybody told Sam & Jeff they should test this? I'm not saying it's a known WTF in Discourse, but given the way that Discourse "works," there's a decent probability... It'd probably be ESC-J for down and ESK-K for up, tho.

2014-06-09 Reply Admin

someguy:
I had to do a double-take after I read this since I saw it was posted by Erik Gern. It's probably the least "Gernified" post I've seen by him.

Yes, that's what made it so exceptional.

2014-06-09 Reply Admin

ZazuYen:
Bill:
Mike R.:
The other extreme: Around here a lot of people just do this:
try { ..... } catch ex { }

When you ask, the most common answer is: "I don't want the application to crash."
But, we're trying to make our computers more human! Something goes wrong... "Meh. I'll worry about it later. Maybe. I really just want to get this done and go back to youtube."
Nothing will instill rage in a seasoned developer like tracking down an inexplicable problem and finding, at the core of it, an empty catch block. Even if there's nothing to do there you should at least log it, and if it fails to be logged then log the logging exception, and if logging the logging exception fails then log the logging exception logging exception, and stop after 4 rounds so it ends up on TDTWTF but doesn't fill up the production logs.

FTFY

2014-06-09 Reply Admin

Peter told the kid he had a much bigger problem, so the kid created a much bigger solution.

Be careful what you say to youngsters.

2014-06-09 Reply Admin

Meh:
Zylon:
Clearly the guy who wrote this always wanted to be a lumberjack.
And that's okay.

THIS! Do we vote for best post?

Well, you obviously shouldn't.

2014-06-09 Reply Admin

I take it you're not a Monty Python fan.

And that's OK.

2014-06-09 Reply Admin

hvd:
I haven't had any experience with Java performance troubleshooting, but do exception handlers really cause overhead, in the common case where no exceptions are thrown? I ask because they don't have to, and don't in other languages/environments: for C++ (depending on the ABI), for example, the runtime is able to detect whether there's a handler without the calling code having to waste instructions on setting up such a handler. And even if Java does have some noticeable cost for setting up the exception handler, how can the complexity of the handler be an issue if the handler isn't invoked?

STFU and stop trying to micro-optimize everything.

duh · 2014-06-09 Reply Admin

I hope I wasn't the only one who thought of badgers upon seeing "LoggerLoggerLoggerLogger".

2014-06-10 Reply Admin

ben:
turtles standing on top of turtles, but what does the frist turtle stand on?

Great A'Tuin, of course

Zemm · 2014-06-10 Reply Admin

fatfacemcfattypants:
sol:
On Error Resume Next

Just use PHP it's built in.

In a lot of our MySQL insert statements we use "insert ignore into table ...". The lead developer even goes through and adds the "ignore" to insert statements. Problem is he even does it to "insert into ... on duplicate key update ..." statements. I can't find anything in the documentation what happens in this case.

2014-06-10 Reply Admin

Chris Angelico:
Logging *can* of course fail. Ever heard horror stories of a server that ran out of disk space when some log file filled it all up, and random daemons start having errors trying to log their errors? That's fun, especially when you can't SSH in because your SSH daemon logs all access... Do *you* have emergency solutions to crazy situations?

Exception is like another kind of return and you can only return one thing. So inevitably, possibly throwing exceptions within an exception means you now have two things to return. In this case he possible wants a container exception with some kind of linked list. Doesn't Java have something like that (previous exception, etc)?

2014-06-10 Reply Admin

A Guy:
How can you type 'ExceptionLoggerLoggerLoggerLogger' without feeling stupid??

The same way you type 'EnterpriseProxyAbstractFactoryFactorySingletonFactoryDecoratorAdapterFactory'.

2014-06-10 Reply Admin

Meep:
hvd:
I haven't had any experience with Java performance troubleshooting, but do exception handlers really cause overhead, in the common case where no exceptions are thrown? I ask because they don't have to, and don't in other languages/environments: for C++ (depending on the ABI), for example, the runtime is able to detect whether there's a handler without the calling code having to waste instructions on setting up such a handler. And even if Java does have some noticeable cost for setting up the exception handler, how can the complexity of the handler be an issue if the handler isn't invoked?

STFU and stop trying to micro-optimize everything.

This is not micro-optimizing, it's practically the opposite: hvd is disputing that there is a performance issue at all. It was the article that claimed the exceptions were causing the bottleneck.

ZazuYen · 2014-06-10 Reply Admin

Heh, thanks! I failed at writing code optimized for TDWTF.

2014-06-10 Reply Admin

Roby McAndrew:
The questions are quite reasonable. If more people put thought into error handling we would be struggling to fill the Friday Error'd column.
The answer is, of course, 42.

FTFY

2014-06-10 Reply Admin

Mike R.:
The other extreme: Around here a lot of people just do this:
try { ..... } catch ex { }

When you ask, the most common answer is: "I don't want the application to crash."

I see this ALL THE TIME. I can't count the number of times that a program gives an "record saved" or some such message, when in fact it didn't save the record. And I start digging through the code to find the problem, and find one of these empty catch blocks. Arrggghhhh. In one case I suggested to the lead developer that we change it to display the text of the exception on the screen. He said we can't do that because we don't want to give the user an incomprehensible technical error message. I replied, So it's better to tell him that his order was processed when it really wasn't? At least if he gets a message, even if he doesn't understand it, he knows that something went wrong. And he replied, I kid you not, that yes, it's better to tell the user that it worked when it didn't than to give him a mysterious error message.

chubertdev · 2014-06-10 Reply Admin

Jay:
I see this ALL THE TIME. I can't count the number of times that a program gives an "record saved" or some such message, when in fact it didn't save the record. And I start digging through the code to find the problem, and find one of these empty catch blocks. Arrggghhhh. In one case I suggested to the lead developer that we change it to display the text of the exception on the screen. He said we can't do that because we don't want to give the user an incomprehensible technical error message. I replied, So it's better to tell him that his order was processed when it really wasn't? At least if he gets a message, even if he doesn't understand it, he knows that something went wrong. And he replied, I kid you not, that yes, it's better to tell the user that it worked when it didn't than to give him a mysterious error message.

Both are really bad, in entirely different ways. Displaying an exception's actual message is a horrible, horrible idea.

2014-06-10 Reply Admin

Who will log errors in the logger? Who will guard the guardians?

2014-06-10 Reply Admin

So what did he actually do in all these higher-level loggers? I mean, I can see saying that if you have some sophisticated, complex logging tool, that if that throws an exception, write a message to a simple flat file saying "logger failed" or some such. But if that fails, what will you do then? Write to a different flat file? Blow smoke out the back of the computer? I think you'd pretty quickly reach a point where you say, And if plan D fails, just crash the program to force somebody to look at it, or maybe continue without logging the error.

Well, I guess that's the point of the story, that the whole thing is crazy. But what did he try to do in the high-level loggers? I can't help but wonder. If he was just trying to log the error to the same logger that failed to log the previous error, that's doubly stupid.

2014-06-10 Reply Admin

chubertdev:
Displaying an exception's actual message is a horrible, horrible idea.

Huh, why do you say that?

Yes, it's conceivable that it could reveal information about system internals that could help a hacker. I'm hard pressed to think of examples, though. So it gives away internal table names or names of programs. So what? Unless you have other security holes, I don't see how that would help anyone.

Certainly a message that said, "Password does not match the correct password of 'foo42#3'" would be a really bad idea. Maybe there are some exception messages that would give away something like that. I suppose as I don't know all the possible exception messages, I should be careful.

I was thinking more of showing a user a message like 'Null pointer exception at plugh.vb line 314'. At least if the user called up and said he got that error, we'd have something to look at.

And obviously a message that says, "No such product in catalog" or "Cannot delete customer account while it has outstanding orders" or something actually meaningful to the user is better than something cryptic. I was thinking about cases more like null pointer exceptions and the like, where it's a programming error that slipped through testing.

chubertdev · 2014-06-10 Reply Admin

http://security.stackexchange.com/questions/4471/is-it-a-vulnerability-to-display-exception-messages-in-an-error-page

It should not be that hard to come up with a line of text that's friendlier and safer.

2014-06-11 Reply Admin

chubertdev:
http://security.stackexchange.com/questions/4471/is-it-a-vulnerability-to-display-exception-messages-in-an-error-page
It should not be that hard to come up with a line of text that's friendlier and safer.

The sheer majority of exceptions wont have anything useful to users except "there was a problem", maybe there was a problem doing x. Typically you want to automate this. It's still useful to actually have meaningful messages (ie what the app was trying to do/expected) in logs for debugging rather than a stack trace. Consider exception throwing as a kind of runtime assertion/automated testing feature.

Unless the exception is specifically related to something the user might have done, I consider it a lost cause to try to put in an error message for a user. By default messages should be for developers. If your app is so buggy that you need users to try to work around themselves by giving extra info all the time such as where it failed, you should give up programming.

So exceptions should never be output to the user when one exception. You create a SafeException class that you might use like this...

if input.password is empty throw new SafeException('Password was empty!');

Alternatively you can use codes and separate presentation from logic.

Personally in my systems I tend to wrap all exceptions that are unsafe (not instance of SafeException) as they reach a boundary layer where they are propagated to a conversion handler in a SafeException. This makes a nice simple single channel of communication. The wrapping process logs, adds a generic message and a time stamp so that the error can be found in logs (an identifier or encrypted logout put are other options). I have so few errors that anything too elaborate is usually unnecessary.

In summary, exception messages should be for programmers.

2014-06-11 Reply Admin

Logger Logger Logger Logger Logger Logger Logger Logger Logger Logger Logger Logger Mushroom Mushroom

2014-06-11 Reply Admin

chubertdev:
Jay:
... I replied, So it's better to tell him that his order was processed when it really wasn't? At least if he gets a message, even if he doesn't understand it, he knows that something went wrong. And he replied, I kid you not, that yes, it's better to tell the user that it worked when it didn't than to give him a mysterious error message.
Both are really bad, in entirely different ways. Displaying an exception's actual message is a horrible, horrible idea.

Telling the user that that it worked it didn't is a horrible, horrible, awful, disastrous, multitudinously horrible awful thing to do.

Give me even a Blue Screen than tell me that everything is fine, my reservations have been approved, just show up after traveling 3,000 miles taking 1 week of time and several thousand dollars. DO NOT TELL ME everything is fine. I much prefer any TDTWF error messages to "OK" when it is NOT OK!!!!!!

2014-06-12 Reply Admin

Jay:
I suppose as I don't know all the possible exception messages, I should be careful.
I was thinking more of showing a user a message like 'Null pointer exception at plugh.vb line 314'. At least if the user called up and said he got that error, we'd have something to look at.

And obviously a message that says, "No such product in catalog" or "Cannot delete customer account while it has outstanding orders" or something actually meaningful to the user is better than something cryptic. I was thinking about cases more like null pointer exceptions and the like, where it's a programming error that slipped through testing.

Well, yes, that is the problem. The possible exceptions that you don't know about are precisely the only exceptions that you will show the user. This is a backwards failsafe, it's like airbags that only deploy while you are not crashing.

However it's a reasonable temporary solution if you don't even have handling for common, understood problems like "no such product" yet. But replacing this, with user-friendly messages for expected exceptions and logging for unexpected ones, should be a priority.

2014-06-12 Reply Admin

Jay:
chubertdev:
Displaying an exception's actual message is a horrible, horrible idea.
Huh, why do you say that?

Because, when you fail, this is what the user sees:

omg.wtf: useless.object.class.Name; IncomprehensibleException  minor code: DEADBEEF  completed: No 	
         at you.are.so.screwed(ValueHandlerImpl.lang:199)  
         at you.paid.good.money.to.download.this.app(CDRInputStream.lang:1429)  
         at and.the.apps.developers.have.no.clue(ValueHandlerImpl.lang:625)  
         at demand.your.refund.now(ValueHandlerImpl.lang:273)
         at because.this.is.but.a.preview(CTROutslutStream.lang:1429)

In fact, I'm a developer, and that's what these stacks look like to me too. If I see this displayed as the first description of the failure, I consider whether I really need to use this application or not.

I would be more tolerant of such failures if they were stored in a log file (or a "Details" tab).

2014-06-12 Reply Admin

ben:
turtles standing on top of turtles, but what does the frist turtle stand on?

It's loggerheads all the way down.

Exceptional Exception Logging Logging Logging

Leave a comment on “Exceptional Exception Logging Logging Logging”