File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Java in General and the fly likes Should you ever catch array bounds exception instead of checking length(s)? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Java in General
Bookmark "Should you ever catch array bounds exception instead of checking length(s)?" Watch "Should you ever catch array bounds exception instead of checking length(s)?" New topic
Author

Should you ever catch array bounds exception instead of checking length(s)?

Ken Blair
Ranch Hand

Joined: Jul 15, 2003
Posts: 1078
I know that you should never use a try/catch block to iterate an array instead of the standard for loop idiom. What if you're doing something that accesses it often and rarely does so with a value out of bounds? Example:



as opposed to:



Assume this is a situation where you will encounter an index that is out of bounds and have to do something logical with it rather than throw an unchecked exception. Also assume that this is called very often and is rarely out of bounds. Would avoiding the length checks when they're rarely needed anyway be good or is it just bad to use an exception unnecessarily even in such circumstances?
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 19064
    
  40

Assume this is a situation where you will encounter an index that is out of bounds and have to do something logical with it rather than throw an unchecked exception. Also assume that this is called very often and is rarely out of bounds. Would avoiding the length checks when they're rarely needed anyway be good or is it just bad to use an exception unnecessarily even in such circumstances?


Maybe a third possibility is to check the range only when you change either the array, the row variable, or the col variable? You can somewhat get the best of both cases.

Having said that, this question is borderline developer's opinion. I am not a fan of strict rules in this regard.

Henry


Books: Java Threads, 3rd Edition, Jini in a Nutshell, and Java Gems (contributor)
Ken Blair
Ranch Hand

Joined: Jul 15, 2003
Posts: 1078
In this particular case I was thinking back to a method I had that returned the height of a specific cell in a table. So the row and col would be different every time as they'd be parameters rather than member variables.
Tony Morris
Ranch Hand

Joined: Sep 24, 2003
Posts: 1608
Doing so would fail a code review in my workplace, under any circumstance... even obsure cases (which yours is not)... even then.


Tony Morris
Java Q&A (FAQ, Trivia)
Scott Selikoff
author
Saloon Keeper

Joined: Oct 23, 2005
Posts: 3716
    
    5

Having said that, this question is borderline developer's opinion.


I agree, although I prefer to avoid catching run-time exceptions when possible because:
  • Better control of recovery. For example, the exception could have been thrown for a negative value or a value greater than the size limit. By checking the conditions yourself, you have better control of recovery for more specific forms of the same exception.
  • If statements are easier to read than try/catch blocks. This is a personal preference at best, but I find if statements easier to split up into sub-methods than try/catch blocks.
  • Too general of exceptions. Some people (scares me) like to catch general exceptions including Throwable/Exception types. In complex applications, you could end up catching Runtime exceptions that are internal to another application that you never intended to catch nor can you do anything with.
  • Wrong exception caught. It doesn't have to be a general exception to catch the wrong one, it could be an identical exception from some other internal class.


  • In general, the only time I tend to catch Run-time exceptions is on the highest delegate level where I determining the output to the client such as outputting a general message to the client instead of an exception.


    My Blog: Down Home Country Coding with Scott Selikoff
    jiju ka
    Ranch Hand

    Joined: Oct 12, 2004
    Posts: 306
    If values for row or column originated in user interface validation should prevent undesired values.

    If values for row or column originated in the code looking for array length will prevent it.

    Prevention is better than recovery, in not so time critical applications.

    Exception handling is recovery part.

    We can prevent most of the unchecked exceptions by proper coding and testing.

    There are certain circumstances where an external service is not available. A checked exception suites these scenarios.

    My rule is 'prevent' an unchecked exception from happening as much as possible. The rest is left to "tester". So far it worked. And I have a good reputation of providing quality code.
    Brian Cole
    Author
    Ranch Hand

    Joined: Sep 20, 2005
    Posts: 863
        
        1
    It's nice to hear people's opinions, but what
    I'd really like to hear is actual performance
    numbers of the two cases. I might be willing
    to lose style points for faster code in some
    situations.

    I often feel dumb checking my array bounds,
    since the lookup code has to go ahead and
    check them again anyway. (That said, I keep
    doing it.) Perhaps in a tight loop where
    out-of-bounds would be rare it would be
    faster to catch the exception instead?
    Has anyone actually measured this?

    A third approach would be to use assertions
    for the index-in-bounds test. This could be
    a win if you think you might ever be comfortable
    turning assertions off. (Not an option if you
    expect out-of-bounds to reasonably occur.)
    [ November 03, 2005: Message edited by: Brian Cole ]

    bitguru blog
    Scott Selikoff
    author
    Saloon Keeper

    Joined: Oct 23, 2005
    Posts: 3716
        
        5

    I often feel dumb checking my array bounds, since the lookup code has to go ahead and check them again anyway.


    I gotta say, this really goes back to who the customer is. If you have a contract with users that says "you are not allowed to use my function unless you adhere to this rule" and it is well documented, then from a business perspective, you have no obligation to ever check the code. Alternatively, if this is a private method you can ignore it too.

    But 999 times out of 1000, its a public method and no one has read any of your documentation at all no matter how well written, so best to *always* check, just make sure you only check on the external layer once (for example, if you've validated the user's input, no need to check it multiple times).

    To me, supportability and stability beat performance every time assuming non-extreme cases.
     
    I agree. Here's the link: http://aspose.com/file-tools
     
    subject: Should you ever catch array bounds exception instead of checking length(s)?