Sign Up

Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.

Have an account? Sign In

Have an account? Sign In Now

Sign In

Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.

Sign Up Here

Forgot Password?

Don't have account, Sign Up Here

Forgot Password

Lost your password? Please enter your email address. You will receive a link and will create a new password via email.

Have an account? Sign In Now

You must login to ask a question.

Forgot Password?

Need An Account, Sign Up Here

Please briefly explain why you feel this question should be reported.

Please briefly explain why you feel this answer should be reported.

Please briefly explain why you feel this user should be reported.

Sign InSign Up

The Archive Base

The Archive Base Logo The Archive Base Logo

The Archive Base Navigation

  • SEARCH
  • Home
  • About Us
  • Blog
  • Contact Us
Search
Ask A Question

Mobile menu

Close
Ask a Question
  • Home
  • Add group
  • Groups page
  • Feed
  • User Profile
  • Communities
  • Questions
    • New Questions
    • Trending Questions
    • Must read Questions
    • Hot Questions
  • Polls
  • Tags
  • Badges
  • Buy Points
  • Users
  • Help
  • Buy Theme
  • SEARCH
Home/ Questions/Q 6112669
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Editorial Team
Asked: May 23, 20262026-05-23T14:46:17+00:00 2026-05-23T14:46:17+00:00

I have read that some of the JVMs out there can optimize code execution

  • 0

I have read that some of the JVMs out there can optimize code execution by removing bounds checking. What I am trying to figure out is what coding technique will work better.

In method example1 below would the JVM ever figure it out and eliminate the bounds checking of the source[index] reference?

Is example2 the better code practice? It would seem so, but in some algorithms inside a loop the index being out of bounds is a normal condition. So you don’t want to be generating tons of Exception objects inside that loop.

public void example1(int [] source, int index) {
    if (index >= 0 && index < source.length)
        System.out.println("Value is " + source[index]);
    else 
        System.out.println("Out of range: " + index);
}

public void example2(int [] source, int index) {
    try {        
        System.out.println("Value is " + source[index]);        
    } catch (IndexOutOfBoundsException exp) {
        System.out.println("Out of range: " + index);
    }
}

These code fragments are only representational. I am aware that in these examples the bounds-checking will hardly matter to performance. However I am working on an embedded protocol application where the redundant bounds checking will add up.

  • 1 1 Answer
  • 0 Views
  • 0 Followers
  • 0
Share
  • Facebook
  • Report

Leave an answer
Cancel reply

You must login to add an answer.

Forgot Password?

Need An Account, Sign Up Here

1 Answer

  • Voted
  • Oldest
  • Recent
  • Random
  1. Editorial Team
    Editorial Team
    2026-05-23T14:46:18+00:00Added an answer on May 23, 2026 at 2:46 pm

    To your first question, in example1 the bounds check can theoretically be eliminated. I’d expect the best modern JIT compilers to do this (e.g. perhaps via common sub-expression elimination in the bounds check when source[index] is expanded). As usual this will be implementation dependent so you can’t rely on it. OTOH even if the bounds check isn’t eliminated the difference will be trivial – you’re hitting the already cached memory location for source.length and doing a couple of integer compares so the overhead is tiny.

    example2 is not good practice – you are hitting an exception but then catching it and continuing as if nothing happened. Unless you are watching stdout closely you might completely miss the fact that there is a bug in your code.

    There are basically two common “good” possibilities depending on what you consider to be a valid input for “index”:

    1. An out-of-bounds index value is
      expected
      and is considered valid input. In
      which case you should test and handle it
      explicitly as in example1. You shouldn’t need to throw any sort of exception in this case.

    2. An out-of-bounds index is unexpected (and is therefore a bug in the calling code). Your code should raise an exception here. If you like you can catch and re-throw the exception with your own message but you could also just let the IndexOutOfBounds exception propagate. Don’t worry about the performance impact of this exception handling – you have just discovered a bug and therefore you want the program to fail as quickly and “loudly” as it can…..

    • 0
    • Reply
    • Share
      Share
      • Share on Facebook
      • Share on Twitter
      • Share on LinkedIn
      • Share on WhatsApp
      • Report

Sidebar

Related Questions

i have read that some machine can't express exaclty floating point number for example
I have read that there is some overhead to using C++ exceptions for exception
I think I read somewhere that some modules only have object oriented interfaces (
I have read from some article that say's Apple doesn't approve the application which
I have read on Stack Overflow some people that have converting to C#2.0 to
I am new to ASP.net MVC architecture. I have read in some articles that
I have read in some of the ClickOnce posts that ClickOnce does not allow
I just got Delphi 2009 and have previously read some articles about modifications that
I have some configuration data in a config file that I read off disk
I have read that after installing some Eclipse plugins manually, one should use the

Explore

  • Home
  • Add group
  • Groups page
  • Communities
  • Questions
    • New Questions
    • Trending Questions
    • Must read Questions
    • Hot Questions
  • Polls
  • Tags
  • Badges
  • Users
  • Help
  • SEARCH

Footer

© 2021 The Archive Base. All Rights Reserved
With Love by The Archive Base

Insert/edit link

Enter the destination URL

Or link to existing content

    No search term specified. Showing recent items. Search or use up and down arrow keys to select an item.