Monday, May 12, 2025 – Last week, while reviewing the overall project, I came across a minor but important bug related to how error messages were being handled across the application. The issue stemmed from an earlier implementation by a previous intern, where the error handling was too generic. In particular, the logic often defaulted to a fallback else condition, which resulted in inaccurate or misleading error messages being shown to users. This became especially problematic in situations where the error was caused by something specific, like a validation issue or a network failure, but the application simply displayed a vague message like “Unexpected error occured.”
To fix this, I refactored the code and improved the error-handling mechanism to deliver clearer and more accurate feedback. I began by updating the try-catch block that handles API calls. First, I checked if the error was an instance of AxiosError. If the error didn’t contain a response (which typically indicates a network issue), I displayed a message stating “Network error.” This ensures that users understand when the issue is with their internet connection rather than with the application itself.
Next, I refactored a helper function responsible for interpreting and extracting meaningful messages from different error formats returned by the API. This function supports multiple known error structures, such as general error messages, validation errors with multiple fields, and fallback cases where the message is returned as plain text or JSON. This is a significant improvement over the previous implementation, which would have shown a single, generic message regardless of the actual issue.
In summary, this small but important update ensures that users are better informed about what went wrong when an error occurs. It enhances the clarity and reliability of our application’s error reporting and contributes to a better overall user experience.