# Windows Found My Bug Before I Did. I Just Had to Read the Error Message.

Sometimes, the hardest part of debugging isn't finding the bug. It's actually paying attention to what the error message is telling you.

Today, I was working on a simple Java task: splitting a string like name=Kwame into a key and a value.

The idea was straightforward:

1. Find the position of =.
2. Extract everything before it as the key.
3. Extract everything after it as the value.

Here's the code:

String text = "name=Kwame";

int index = text.indexOf('=');

String key = text.substring(0, index);
String value = text.substring(index + 1);

System.out.println(key);
System.out.println(value);

Expected output:

name
Kwame

Simple enough, right?

Where I went wrong

My first implementation looked like this:

String value = text.substring(index);

I thought I was extracting the value after =.

But there was one problem.

substring(index) starts extracting at the index you provide. It doesn't skip that character.

So instead of getting:

Kwame

I got:

=Kwame

Java didn't complain. The code compiled and ran perfectly fine. It simply returned something I wasn't expecting.

Then Windows stepped in.

I eventually passed that value into a file path, and Windows threw this exception:

Illegal char <:> at index 2: =C:/Documents

At first, I was looking everywhere except the actual problem.

But look closely:

=C:/Documents
^

The unwanted = was still there.

The error message had practically pointed at the problem. I just hadn't paid enough attention to it.

What I learned

1. Java's substring indexing starts at zero.

String text = "name=Kwame";
int index = text.indexOf('=');

String key = text.substring(0, index);
String value = text.substring(index + 1);

Remember:

• substring(start, end) includes start but excludes end.
• substring(start) extracts from start to the end.
• index + 1 skips the delimiter.

2. Code can compile and still be logically wrong.

A successful compilation doesn't guarantee that your program is producing the expected result.

3. Read the error message before rewriting your code.

Error messages often contain valuable clues, including the exact input that caused the failure.

Sometimes the answer is already there.

I'm back on the learning streak, and these little debugging experiences are teaching me more than I expected.

Your turn

What's an off-by-one error or silly debugging mistake that cost you way more time than it should have?

I'd love to hear your stories.

Java #Programming #Debugging #SoftwareEngineering #LearningInPublic