Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror

Slashdot videos: Now with more Slashdot!

  • View

  • Discuss

  • Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).

×
User Journal

FortKnox's Journal: [Java] You know when you are knee deep in crap code.... 16

Journal by FortKnox
I should submit this to the daily wtf...
You know you're knee deep in crap code when you see this in production:

// ...
} // end try
catch(ArrayIndexOutOfBoundsException e)
{
}

I'm one of those that hates swallowing exceptions (yeah, there are rare exceptions to that rule), but to catch an array index out of bounds exception... and then swallow it? Gah!

This discussion has been archived. No new comments can be posted.

[Java] You know when you are knee deep in crap code....

Comments Filter:
  • by dthable (163749)
    I always code the main part like:

    public static final int main() {
        try {
        } catch( Exception e) {
        }
    }

    Why do I want to see all that junk on my screen?
  • catch (Exception e) {

    }
    Not sure if that would actually work, not being a Java guy, but you get the point. :-)
    • That's not bad. In java, you can catch multiple exceptions, and put in a 'just in case' sort of thing, like so:

      try
      {
      //...
      }
      catch(BadInputException bie)
      {
      //do something
      }
      catch(IOException ioe)
      {
      //do something else
      }
      catch(SQLException sqle)
      {
      //do something else
      }
      catch(Exception e)
      {
      //just in case another (new?) exception passed us by
      }

      In Java, Exception is the root object in the exception inheritence tree, but catches go in order so you catch everything you are prepared to handle in particular ways, then do

      • I'm pretty well-acquainted with the Java exception system. My one Java project was wrapping a C library (converted from FORTRAN!) with a JNI object so that the Java guys could use it in their code.

        The running joke after that was that "Randy doesn't know how to program in Java, but he could probably write a JVM if we needed it." :-)

        Java's exception system is fairly similar to Python's, which is a language I'm fluent in. I'd give you an example, but /. makes posting whitespace sensitive Python an exerci

  • an example of *exactly* this and the exception, for good reason is swallowed. a batch job that parses an excel spreadsheet. if the producer of said spreadsheet did not provide data for a cell, we don't want to stop doing things or waste time/resources reporting it. just move along and forget it ever happened.

    building a fault-tolerant system while saving resources is, in many cases, good programming. especially in this case when the job itself consumes *huge* amounts of resources and can often take 20+ hour
    • But this is a case of writing options for a select dropdown in a JSP (ancient servlet-jsp app). There is no excuse of it and I'm embarassed that this is in a piece of production code I have to maintain.

      And I'm actually afraid to take it out ;)
      • Not being fluent in every language I program in, I at least take the time to note why I do things that seem odd.

        I guess the guy didn't leave behind any comments?
        • I guess the guy didn't leave behind any comments?

          He must've been a Real Programmer [funnies.paco.to]. "If it was hard to write, it should be hard to understand and harder to modify." :-)

      • But this is a case of writing options for a select dropdown in a JSP (ancient servlet-jsp app). There is no excuse of it and I'm embarassed that this is in a piece of production code I have to maintain.

        When I first saw it, I thought it was an optimization in old Java code (remember when it used to be much quicker to run off the end of the array and catch the exception, rather than use a for loop?)... Is there a concurrency problem, so the array could shrink while this method runs? If the original coder hi

        • Is there a concurrency problem, so the array could shrink while this method runs?

          I'm trying to think that one through, and it doesn't make much sense. Arrays are not dynamically resizable, they're fixed in size once created.

          I suppose someone could replace the array with a different one inside the loop that was accessing the array. The length attribute of the array would still be available, however, and so there would still be no reason that a reasonable program should generate this exception.

          Am I mi

          • I'm trying to think that one through, and it doesn't make much sense. Arrays are not dynamically resizable, they're fixed in size once created.

            Yep - if it's a true array (not a Vector or similar), you'd be replacing it with one of another size. Being a C programmer at heart, that's the only resizing there is for arrays :-) (You can actually get similar exceptions out of the newer container classes, if you modify them in non-threadsafe ways - not the exception listed in the JE, though, IIRC.)

            I suppose som

    • Still, the length of the array should be available. Are you arguing that a 'for' loop is fundamentally less efficient than an infinite loop and exception handler when the data sets are huge? Sam, if you are watching, this is one of those places where any good coder should put a comment.

  • You know, judging by how much malformed HTML and broken quotes ends up coming up in the Daily WTF forum, I think The Daily WTF should be a subject of the Daily WTF.

Nothing in progression can rest on its original plan. We may as well think of rocking a grown man in the cradle of an infant. -- Edmund Burke

Working...