• Larry (unregistered)

    TRWTF is JiBX.

  • QJ (unregistered)

    The real WTF is not leaving a gap between the class name and the error message. It makes the system output look messy.

  • Java Engineer (unregistered)

    Someone needs to inform Brian that System.exit does not shut down the Application Server.

  • (cs)

    I finally understand why Java's security model is so torturous:

    It's to protect everyone else against people who write code like this.

  • Anonymous (unregistered)

    Calling System.exit on a webserver? I've seen a lot of crap in my time but that's a new one on me, great job.

  • (cs)

    It is not that hard to create and install your own SecurityManager that prevents System.exit from executing. But this would surely have been mentioned by the OP if it had been done.

  • PG4 (unregistered)

    You see that is really a DOS attack vector. Therefor CERT will be issuing an alert on that, requiring that the application be upgraded. within 24 hours.

  • d00d (unregistered)

    That's horrible- everyone knows that the right way to deal with a server issue is to show an error dialog box.

  • (cs) in reply to QJ
    QJ:
    The real WTF is not leaving a gap between the class name and the error message. It makes the system output look messy.

    Please feature this comment. It's the funniest thing I've read on these stories in the last 3 weeks.

  • XXXXX (unregistered)

    I for one think every language should have a System.crash() or equivalent for just this kind of opportunity for overreaction.

  • Anonymous Guy (unregistered) in reply to Anonymous

    i've had to deal with a few of those. An ex co-worker of mine thought it was a good idea to do a System.exit when various errors occured instead of handling it....those were fun to debug when they would randomly happen at first and we didn't know thats what was going on. We have since removed those and handle them more gracefully.

  • Java Engineer (unregistered)

    Now I see the problem: it should be log.fatal instead of log.info.

    Seriously, though. How do we know that this is NOT the write thing to do here? What if this is a short lived application that exists only to call that service? What if it is called by a process that checks the error code when complete and does something to handle that accordingly? If an external application is supposed to do something, exceptions do not propagate outside that process. Brian may realize this when he is older.

  • (cs) in reply to Anonymous
    Anonymous:
    Calling System.exit on a webserver? I've seen a lot of crap in my time but that's a new one on me, great job.
    It works fine in my test environment.
  • (cs)

    The ideal way to handle the errors would be to have ITAPPMONROBOT bring a hammer down on the server.

  • socknet (unregistered) in reply to QJ
    QJ:
    The real WTF is not leaving a gap between the class name and the error message. It makes the system output look messy.

    Agreed - this code needs to be refactored to include that gap. This is difficult to maintain and would only just pass a code review.

  • Jeff (unregistered) in reply to Java Engineer
    Java Engineer:
    Seriously, though. How do we know that this is NOT the write thing to do here? What if this is a short lived application that exists only to call that service?
    There's no such thing as a short-lived application in Java, where any program takes several minutes to start up.
  • Franz Kafka (unregistered)

    I worked with a guy like that once - his response to getting an exception on a java web service was to kill the process. When I asked him about it (he just checked it in one day), he gave me some song and dance about unknown states.

  • C-Octothorpe (unregistered) in reply to Franz Kafka
    Franz Kafka:
    I worked with a guy like that once - his response to getting an exception on a java web service was to kill the process. When I asked him about it (he just checked it in one day), he gave me some song and dance about unknown states.

    Such as his future employment state at your company?

  • Robo (unregistered) in reply to XXXXX
    XXXXX:
    I for one think every language should have a System.crash() or equivalent for just this kind of opportunity for overreaction.

    System.releaseMagicSmoke();

  • C-Octothorpe (unregistered)

    You know what, despite how shitty the "handling" of this exception is I would still rather have this x1000 in production code than some mysterious try/catch swallowing exceptions silently buried deep in one layer or another.

  • Zapp Brannigan (unregistered) in reply to d00d
    d00d:
    That's horrible- everyone knows that the right way to deal with a server issue is to show an error dialog box.
    That's what I do. But I'm a Windows programmer (MS Access and VBA). My laptop is also the server. It's a bummer to shutdown or reboot because it's our etl, e commerce, billing and human resources server.
  • Design Pattern (unregistered) in reply to C-Octothorpe
    C-Octothorpe:
    You know what, despite how shitty the "handling" of this exception is I would still rather have this x1000 in production code than some mysterious try/catch swallowing exceptions silently buried deep in one layer or another.
    All this logs is the name of the class decorated with "INVALID RESPONSE CODE!".

    It is swallowing the actual response code, it is swallowing the URL it was trying to connect to, it is swallowing the actual query parameters.

    So this is almost as shitty as it can get.

  • C-Octothorpe (unregistered) in reply to Design Pattern
    Design Pattern:
    C-Octothorpe:
    You know what, despite how shitty the "handling" of this exception is I would still rather have this x1000 in production code than some mysterious try/catch swallowing exceptions silently buried deep in one layer or another.
    All this logs is the name of the class decorated with "INVALID RESPONSE CODE!".

    It is swallowing the actual response code, it is swallowing the URL it was trying to connect to, it is swallowing the actual query parameters.

    So this is almost as shitty as it can get.

    Agreed. I never sais it was good, I just said that any logging is better than no logging. At least in this case you know where it's happening (class name), and a loose idea as to why as well ("INVALID RESPONSE CODE"). Better than "hmm, that's wierd. It just shuts down... Let's try it again".

    I would never advocate that this is the desired method for error handling, but it's less worse, and you can't really disagree with that...

  • (cs)

    Gee! Big red switch done in JVM. What a concept!

  • grumpy (unregistered)

    Almost the exact opposite of a silent fail. The only things missing are a klaxon and a hammer to the forehead and we're there. A beaut.

  • JJ (unregistered) in reply to Java Engineer
    Java Engineer:
    How do we know that this is NOT the write thing to do here?
    Correct. It could in fact be exactly the opposite: the read thing to do.
  • Mr.'; Drop Database -- (unregistered) in reply to XXXXX
    XXXXX:
    I for one think every language should have a System.crash() or equivalent for just this kind of opportunity for overreaction.
    .NET has Environment.FailFast for this purpose.
  • Gary (unregistered)

    Everyone's focusing on the error handling WTF (poorly log & then ungracefully die).

    By my reading, TRWTF is that if the request comes back with anything other than 200 OK, then the app dies. Because no one could ever get a 4xx or 500 error, right?

    Maybe the same coder wrote the other side of the service with EXQUISITE error handling that ALWAYS produces a 200 OK response, CAREFULLY logs the errors, and passes the error back as a payload inside the ALWAYS successful http response to the calling service, which handles it PERFECTLY via pastWxHourly.

  • David Wright (unregistered) in reply to Mr.'; Drop Database --
    Mr.'; Drop Database --:
    XXXXX:
    I for one think every language should have a System.crash() or equivalent for just this kind of opportunity for overreaction.
    .NET has Environment.FailFast for this purpose.
    Ah you youngsters. Back in the day, REAL programmers coded in Assembly, and for this fault they had the HCF instruction. "Halt and Catch Fire".
  • Pr0grammer (unregistered) in reply to David Wright
    David Wright:
    Mr.'; Drop Database --:
    XXXXX:
    I for one think every language should have a System.crash() or equivalent for just this kind of opportunity for overreaction.
    .NET has Environment.FailFast for this purpose.
    Ah you youngsters. Back in the day, REAL programmers coded in Assembly, and for this fault they had the HCF instruction. "Halt and Catch Fire".
    ]

    Real programmers code with butterflies.

  • Doesn't go far enough (unregistered)

    It should exec 'shutdown -h now' instead

  • 'tis I (unregistered) in reply to Anonymous Guy
    Anonymous Guy:
    i've had to deal with a few of those. An ex co-worker of mine thought it was a good idea to do a System.exit when various errors occured instead of handling it....those were fun to debug when they would randomly happen at first and we didn't know thats what was going on. We have since removed those and handle them more gracefully.

    Phew!! Thank goodness for that - Waiter, bring me a cigar to enjoy during the next story!!

  • (cs) in reply to Gary
    Gary:
    Everyone's focusing on the error handling WTF (poorly log & then ungracefully die).

    By my reading, TRWTF is that if the request comes back with anything other than 200 OK, then the app dies. Because no one could ever get a 4xx or 500 error, right?

    Maybe the same coder wrote the other side of the service with EXQUISITE error handling that ALWAYS produces a 200 OK response, CAREFULLY logs the errors, and passes the error back as a payload inside the ALWAYS successful http response to the calling service, which handles it PERFECTLY via pastWxHourly.

    Nobody's bothered to comment on TRWTF as you've pointed it out because it's too obvious. Which is why QJ's comment (3rd or 4th, early on) was so funny, because it picked up on something utterly blatantly trivial. Sorry, didn't think this needed explaining.

  • maddaveyflint (unregistered)

    Time to dust off and port that old assembler instruction from the mainframe days - HCF

  • Joe (unregistered) 
      } else {
-   logger.info(this.getClass().getName() + "INVALID RESPONSE CODE!");
    System.exit(1);
+   logger.info(this.getClass().getName() + "INVALID RESPONSE CODE!");
  }

    Patch applied, the PR about the poorly-formatted log message have been resolved.

  • SG_01 (unregistered)

    TRWTF is that it fails on redirects ^^

  • Simon (unregistered) in reply to Java Engineer
    Java Engineer:
    Someone needs to inform Brian that System.exit does not shut down the Application Server.

    Well, not if it's a well-designed application server, at least. In an off-the-shelf server, hosted apps generally can't affect the container itself - but there's no reason someone couldn't build their own 'lightweight' app server that doesn't care for such constraints...

  • Herby (unregistered) in reply to XXXXX
    XXXXX:
    I for one think every language should have a System.crash() or equivalent for just this kind of opportunity for overreaction.

    Some systems did:

    BRS 131B

    Extra credit: Tell us what the system was. This was a standard system call, but you needed privilege to use it (after they patched the system where you could work around it!).

  • Vexorg (unregistered)

    President Madagascar, someone just got a 500 error in Brazil!

  • (cs) in reply to Java Engineer
    Java Engineer:
    Someone needs to inform Brian that System.exit does not shut down the Application Server.

    No, it halts the JVM on which the app server is running on instead :)

    This is what JBoss does when you call System.exit(1) in a servlet.

    JBoss AS:
    16:00:06,121 INFO [ServerImpl] Runtime shutdown hook called, forceHalt: true 16:00:10,620 INFO [ServerImpl] Shutdown complete Shutdown complete Halting VM
  • (cs)

    What's the point of working when such an error occurred? I can't take it any more!

  • (cs) in reply to Scythe
    Scythe:
    What's the point of working when such an error occurred? I can't take it any more!

    "The application's crashed, boss. Can't do anything, boss. I'm gonna go home."

  • QJ (unregistered) in reply to Joe
    Joe:
      } else {
-   logger.info(this.getClass().getName() + "INVALID RESPONSE CODE!");
    System.exit(1);
+   logger.info(this.getClass().getName() + "INVALID RESPONSE CODE!");
  }

    Patch applied, the PR about the poorly-formatted log message have been resolved.

    Hey, fine work.

    I say! I haven't seen any further instances of this error message since you did that fix. You must have fixed the bug! I'm putting you up for a commendation. Expect a payrise and a promotion presently. I wish your colleagues were as efficient and responsive to our demands.

  • Java Engineer (unregistered) in reply to safarmer
    safarmer:
    Java Engineer:
    Someone needs to inform Brian that System.exit does not shut down the Application Server.

    No, it halts the JVM on which the app server is running on instead :)

    This is what JBoss does when you call System.exit(1) in a servlet.

    JBoss AS:
    16:00:06,121 INFO [ServerImpl] Runtime shutdown hook called, forceHalt: true 16:00:10,620 INFO [ServerImpl] Shutdown complete Shutdown complete Halting VM
    Uh...well why don't you upgrade to a version that wasn't written in 1997? Seriously. I was still in high school back then. I don't have much expertise on the 1.2 JVM.
  • drusi (unregistered) in reply to whiskeylover
    whiskeylover:
    The ideal way to handle the errors would be to have ITAPPMONROBOT bring a hammer down on the server.
    ITAPPMONROBOT would never do such a thing. He is a peaceful robot, who asks only that you answer his pings. He could ask someone why you're not answering, but--but what if he bothers them? No, it's safer to just keep waiting, and just keep ejecting. Maybe this time it'll be good enough. Maybe this time.
  • iToad (unregistered)

    Not enough restoration to initial state. To be really safe, it should call System.reboot().

  • Win Su (unregistered)

    I go out drinking with Alex last night and he still not in?

    He a man not able to handle sake.

  • (cs) in reply to Jeff
    Jeff:
    Java Engineer:
    Seriously, though. How do we know that this is NOT the write thing to do here? What if this is a short lived application that exists only to call that service?
    There's no such thing as a short-lived application in Java, where any program takes several minutes to start up.

    Are you serius? I have seen lot of websites built making usage of java technology which were super fast.

  • nerfer (unregistered)

    Add another WTF to this - this story has been bypassed on the home page, but you can navigate to here from the next day or previous day's story.

  • (cs) in reply to Java Engineer
    Java Engineer:
    safarmer:
    Java Engineer:
    Someone needs to inform Brian that System.exit does not shut down the Application Server.

    No, it halts the JVM on which the app server is running on instead :)

    This is what JBoss does when you call System.exit(1) in a servlet.

    JBoss AS:
    16:00:06,121 INFO [ServerImpl] Runtime shutdown hook called, forceHalt: true 16:00:10,620 INFO [ServerImpl] Shutdown complete Shutdown complete Halting VM
    Uh...well why don't you upgrade to a version that wasn't written in 1997? Seriously. I was still in high school back then. I don't have much expertise on the 1.2 JVM.

    That is on Jboss 5.1.0.GA on a Java 6 JVM. I guess you must have only just graduated then?

Leave a comment on “Serious Failure”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article