Win a copy of Design for the Mind this week in the Design forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

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

 
Ken Blair
Ranch Hand
Posts: 1078
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Marshal
Pie
Posts: 20997
76
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
Ken Blair
Ranch Hand
Posts: 1078
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 1608
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Doing so would fail a code review in my workplace, under any circumstance... even obsure cases (which yours is not)... even then.
 
Scott Selikoff
author
Saloon Keeper
Posts: 4010
18
Eclipse IDE Flex Google Web Toolkit
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
     
    jiju ka
    Ranch Hand
    Posts: 308
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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
    Posts: 903
    1
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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 ]
     
    Scott Selikoff
    author
    Saloon Keeper
    Posts: 4010
    18
    Eclipse IDE Flex Google Web Toolkit
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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.
     
    • Post Reply
    • Bookmark Topic Watch Topic
    • New Topic