Expect the Unexpected: Some Words about Errors

     For all ‘Happy Path’ developers, proper error handling is a fundamental feature of software, and it is quite possible that error handling is for half of your code.

 

Expect the unexpected: not all English postboxes are red. This Victorian one stands in Dublin.

 

There two types of errors:

• Retryable Error
• Permanate Error

Retryable error: a temporary issue has occurred. a retry is likely successful. Example causes: firewall reboot, db maintenance, HTTP 5XX.

Permanent error: error where a retry will always end-up with an error. Example: HTTP4XX, NPEs (Null Pointer Exceptions).

After a retry sequence, Retryable errors should become permanent errors.

And at last, don’t forget Logging and Monitoring of errors.

How to Fix NPEs forever

Null is biggest flaw of Java, saying some developers. Null causes NPEs causes crashing software. IMHO this is the same vibe as C vs Rust and I totally disagree. Crashing software is caused by developers and not by the programming language.

The easiest and best way to prevent NPEs is … proper exception handling. It is as simple as it sounds.

Bye the way, NPEs are often a side effect of OOP. All Objects are unsafe until you checked them. But checks are unsafe so go with exception handling.

 

 

Exception handling - resilience in small

On of the most discussed software development topics is the right exception handling. Exception handling is one of the basic building blocks of resilience and without any surprise the correct exception handling depends on your application.

But here some well working tips to keep exception handling easy:

1. Find out how important is this code place. If you compare it with a car, is it the breaker or is it the seat heating.
2. If your code is the "seat heating" category then:
1. Catch the exception
2. Log the exception as error.
3. Maybe count the errors as metric and put the metric on a dashboard.
3. If your code is in the "brake" category then
1. Maybe catch and log the exception with the context e.g. the related method parameter
2. Throw re-throw the exception and handle it on the presentation layer (front end)
4. If you can't clearly decide between the categories "seat heating" and "brake"
1. handle the exception like category "seat heating"
2. create an alert on the metric
5. If you have an fallback use the fallback and count the usage via log message or as metric