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

Debugging can be a frustrating process, especially when the issue lies not in finding the bug, but in recognizing the clues the error message provides. Recently, I encountered such a situation while working on a straightforward Java task involving splitting a string into key and value pairs.

The task was simple: given a string like "name=Kwame", I needed to extract the key ("name") and the value ("Kwame"). I naively believed my implementation was correct, but there was a subtle mistake that led to unexpected results.

My initial code looked like this:

String text = "name=Kwame";

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

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

String value = text.substring(index);

I thought I was correctly extracting the value after the equal sign. However, I overlooked the fact that Java's substring method includes the starting index but excludes the ending index. So, by using substring(index), I was actually including the equal sign in the extracted value, resulting in " =Kwame" instead of the expected "Kwame".

Java didn't raise any warnings or complaints about the code, as it compiled and ran without issues. But here's where Windows came in to save the day. When I passed the problematic value into a file path, Windows threw an exception:

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

At first, I searched everywhere except the actual problem. The error message, however, was pointing straight to the issue. After closely examining the output, I realized that the unwanted equal sign was still present in the value.

This experience taught me several valuable lessons:

1. Java's substring indexing starts at zero. When using substring(start, end), it includes the start index but excludes the end index. substring(start) extracts from the start index to the end of the string. In my case, using substring(index) included the index character itself, leading to the extra "=" in the extracted value.

2. Code can compile and still be logically incorrect. A successful compilation doesn't guarantee that the program will produce the desired outcome. I had written code that compiled but behaved incorrectly due to the off-by-one error in substring indexing.

3. Always pay attention to error messages. They often contain crucial clues, including the exact input that caused the failure. Sometimes, the answer is right there in the error message, waiting to be noticed.

This incident reinforced the importance of carefully reading error messages and not dismissing them as mere noise. They can be powerful tools in identifying and resolving issues, even in seemingly straightforward tasks.

What debugging mistakes or off-by-one errors have you encountered that took longer than expected to solve? I'd love to hear your stories and learn from your experiences.