A while ago, I cleaned up a small Java service that handled a lot of string parsing: user input, configuration values, imported CSV data, etc.—all the common scenarios where “it looks fine, but causes problems in the production environment.” Initially, the bugs weren’t serious. For example, a null value, an incorrect index, and an ugly NumberFormatException exception because a field that should have been a number type was instead "123ABC". Nothing special. But these bugs combined were enough to make the entire process extremely fragile.
That was the point where I stopped treating string exceptions as something to “handle later.” In Java, exception handling is the mechanism that lets us catch runtime errors before they take the whole program down. The basic tools are the ones everyone knows — try, catch, finally, throw, and throws — but the difference in a real project is whether you actually use them in a way that helps you debug the problem, not just hide it.
try is used to store code that might encounter errors.catch is used to handle error conditions.finally is used to clean up code or perform consistent logging, regardless of whether the operation succeeds or fails.throw is used to explicitly throw an exception when data is clearly unavailable.throws is used to indicate that a method might propagate an exception to its parent method.
Common String Exceptions in Java
When I was going through the string-handling code, three exceptions kept showing up again and again. They are simple on paper, but in practice they usually mean the input path is not as clean as we thought.
NullPointerException
This was the first problem I encountered. During code review, a string looked fine, but in a certain execution path, it was actually null. The error immediately became apparent when we tried to read its length.
public class NullStringExample {
public static void main(String[] args) {
String str = null;
try {
System.out.println(str.length());
} catch (NullPointerException e) {
System.out.println("Caught Exception: String is null!");
}
}
}At runtime, str is null, so calling str.length() triggers a NullPointerException. The catch block prevents the whole program from crashing and gives a message that is at least useful when I am looking through logs later. That mattered more than I expected. In one of our test runs, the stack trace pointed straight to the length call, and that told us the real issue was upstream — the value was never initialized properly.
StringIndexOutOfBoundsException
The next problem is more subtle. Our code assumes the string is long enough, but this assumption is incorrect. The code only fails when a shorter value is received.
public class StringIndexExample {
public static void main(String[] args) {
String str = "Java";
try {
char ch = str.charAt(10);
} catch (StringIndexOutOfBoundsException e) {
System.out.println("Caught Exception: Index out of bounds!");
}
}
}Here, str.charAt(10) is invalid because "Java" only has 4 characters. I remember this one because the bug was not obvious from the surrounding code. The string came from a branch that had passed validation in most cases, but one special input broke the assumption. Once the exception appeared, it became clear that we needed to check the string length before trying to read a character at a fixed index.
NumberFormatException
This is probably the most common problem we encounter in the parsing process. The string looks like a number at first glance, but it hides an incorrect character.
public class NumberFormatExample {
public static void main(String[] args) {
String str = "123ABC";
try {
int number = Integer.parseInt(str);
} catch (NumberFormatException e) {
System.out.println("Caught Exception: Invalid number format!");
}
}
}Integer.parseInt(str) expects a clean numeric value. As soon as "ABC" is present, Java throws a NumberFormatException. In our case, the data came from an external source, so this was less about “bad code” and more about “bad assumptions.” After seeing this a few times in logs, I started adding more explicit checks and clearer error messages before the parse step. It saved us from chasing misleading downstream failures.
Best Practices for Exception Handling with Strings
After dealing with these cases a few times, I stopped thinking of exception handling as just a safety net. In practice, it became part of the debugging path.
Validate Input Before Processing
This is the first thing I do now. If a string can be null or an empty string, I won’t wait for Java to throw an exception to remind me.
if (str != null && !str.isEmpty()) {
System.out.println(str.length());
}That one check removed a surprising amount of noise from our logs. It also made it easier to tell the difference between “bad input” and “real bug.”
Use Specific Exceptions
I used to see a lot of code catching Exception everywhere. It works, but it also hides too much. Once we narrowed the catches to specific exceptions like NullPointerException or StringIndexOutOfBoundsException, debugging became much easier. I could tell immediately what kind of failure had happened instead of guessing from a generic error handler.
Avoid Silent Failures
This one came up after we had a few cases where the code caught an exception and then did nothing. No log, no message, no clue. That kind of failure is worse than a crash in some systems because it looks “fine” while producing wrong output.
Now I always try to log the exception or at least return a meaningful message. Even a simple note like “invalid number format” can save time later when someone else is reading the logs at 2 a.m.
Combine try-catch with Finally
I still use finally when I need cleanup or consistent reporting. In the string-processing code, it was useful for logging which record had just been handled, regardless of whether the parse succeeded or failed. That consistency made it much easier to trace a batch run line by line.
Step-by-Step Example: Safe String Manipulation
This was the part of the project where everything came together. We had a list of strings, and some were valid, some were null, and some looked like numbers but were not really numbers. I wanted one flow that could survive all of that without breaking the loop.
public class SafeStringManipulation {
public static void main(String[] args) {
String[] strings = {"Hello", null, "1234", "Java"};
for (String str : strings) {
try {
System.out.println("String length: " + str.length());
int number = Integer.parseInt(str);
System.out.println("Converted number: " + number);
} catch (NullPointerException e) {
System.out.println("Error: String is null!");
} catch (NumberFormatException e) {
System.out.println("Error: Cannot convert string to number: " + str);
} finally {
System.out.println("Processed string: " + str);
System.out.println("-----------------------------");
}
}
}
}This precisely reflects the type of problem we encountered. The loop processes the string array one by one. If a string is null, a NullPointerException is caught. If the string is not a number, a NumberFormatException is handled. Furthermore, the finally function runs every time, meaning that even if problems occur, the logs remain consistent.
What I like about this structure is that it ensures batch processing continues. Even if an error log appears, it won’t prevent the processing of the rest of the data. This alone is a huge improvement. Previously, a malformed value could halt the entire run, and error reports were too vague and useless.
The final output is not only safer but also easier to debug. I can see precisely which string is wrong, why it is wrong, and how the subsequent processes proceed. This makes a significant difference compared to previous versions.