Comments - in methods are only useful if they tell you something that is not immediately obvious when you read the code. Your code is immediately obvious, and thus the comments inside the method are completely redundant. I have a note a little later about your JavaDoc though....
Exceptions - In many ways the difference between when checked and unchecked exceptions are useful, is easy to determine:
- If something fails because the programmer using your code is an idiot (or needs a smack to the side of the head), then throw an unchecked exception.
- If something fails because of an environmental situation beyond the control of the programmer, then throw a checked exception.
In your case, if the programmer gives you garbage, throw an unchecked exception.... and there is essentially nothing environmental that can go wrong. So, no checked exceptions from your method.
Reliability - what can go wrong? In this case, right now, nothing. If something goes wrong it is either because the person using the method is an idiot, or you are an idiot. in either case, you will immediately be aware of that. Your code is simple, and works. For larger functions, it may not be so clear...
But, reliability is about more than what is happening now. Reliability is making sure that things work in the future too. So, to improve reliability, write tests. Make the tests run every conceivable condition through the code. Run the tests every time you change the code.
That is what makes code reliable. Tests. Tests, tests, and more tests. Then Regression tests, and compatibility tests. There is a common theme here, can you spot it?
Scalability - this is a buzz-word that that you threw in because right now it is popular. What influences could introduce scalability problems in your code. In essence, only one thing: very large Strings. With current and older versions of Java (less than 3 or 4 months old), the memory is shared between String values. In your case, doing
String.substring(....) does not take much more memory (about 24 to 64 bytes depending on the JVM). In newer versions of Java (recent Java7 fic-packs and Java8), the substring command will copy the relevant inner memory of the String, and thus will take much more memory. Your code could have scalability problems since it will require a large amount of additional memory each time you do an insert.
Now, whether that is a thing you should worry about.... no, I don't think so. If you have Strings that large, you will have other problems first.
Performance - Yes, it can be faster. Is the improvement meaningful, I doubt it, but, for the record:
you are checking your input values for nulls, and index constraint violations. These exceptions will be thrown anyway, but with default messages. If you remove the explicit checks, you will not actually lose any functionality (except for less meaningful exception messages), and you will gain performance.
The String concatenation in this line here:
st.substring(0, index)+ch+st.substring(index, st.length())
is creating a new StringBuilder instance, two new String objects, concatenating them, and then converting the result to a String. By my count that is three Strings, and a StringBuilder.
You can do better by having just two char arrays, and a String.
char chars = str.toCharArray();
chars = Arrays.copyOf(chars, chars.length + 1);
System.arrayCopy(chars, index, chars, index + 1, chars.length - index - 1);
chars[index] = ch;
return new String(chars);
Whether the marginal improvement will help you or not is uncertain....
Thread-Safety - no problems.... there are no external references, and it is fully 'A-OK'.
I am a firm believer in JavaDoc. Depending on your circumstances, JavaDoc can be less important. Any time I wrote code that is more 'serious' (I expect anyone to have to maintain), I write comprehensive JavaDoc. IDE's make this relatively easy. Your JavaDoc is not complete.
You do not describe the input values appropriately, and there is not enough detail in the
As for declaring the thrown unchecked exceptions.... no. Don't do it... see this Exception Tutorial here, but, you should document them anyway in the JavaDoc.
The JavaDoc is your communication with other programmers. Help them by giving good documentation.
Similarly, your actual exceptions are your communication with other programmers... help them too. Currently your exceptions are poor... consider these changes:
throw new NullPointerException("Null String input value: st");
throw new IndexOutOfBoundsException("No such index " + index
+ " in a String of size " + st.length()
+ ". Expect index value 0 <= index <= " + st.length());