Null, Validations and Exceptions

Image for post
Image for post

Engineering means coding. However how many times do we consider proper error handler? Most of the languages like Java, .NET, Python, C++ can be a very trick in the sense of handling errors. Business validations are like tests but they are hardcoded on the software and run part of the main flow of our applications. We need to worry not only with the “Happy Path” but also with the “What if” moments where things might not happen as we expect. There are many different opinions and options around in sense of validations, exceptions, and error handling especially in a language like Java. Error handling, Exceptions, and validations are a critical part of making systems more reliable and hardening production I would argue. Amazon Builder library talks about that in the context of avoiding Circuit Breakers and hardening the main execution path and make running code more reliable.

Null The billion Dollars Mistake

Java has the @NotNull annotation. Which is fine but IMHO everything should be NotNull by default and that’s one interesting thing about Kotling where the default is different them java. Go language does not have Null as well. How could we about null? Validations are the answer! When you validate you can return some default value or Exception depending on the Case. Look google Gson lib for example.

Validations First

Exceptions Best Practices

  • Item 49 — Check Parameters for Validity
  • Public/protected methods use @throws on Javadoc
  • Objects.requireNonNull
  • @Nullable when the parameter can be null
  • Non-public method(private) can check parameters with assertions (assert)
  • Item 69: Use Exception only for exceptional conditions (Dont use for ordinary control flow)
  • Item 72: Favor the use of Standard Exceptions
  • Item 73: Throw Exceptions appropriate to the abstraction (High level would catch lower level)
  • Item 74: Document all exception throw by each method (/** Javadoc @throws */
  • Item 75: Include failure capture information in the detail message
  • Item 76: Strive for failure atomicity (Generally Exception should leave the object how it was before the exception)
  • Item 77: Don’t ignore Exceptions

Exceptions should be used to blow the program not to control execution flow. You might realize some item numbers are missing on my list. That’s by design because I also dont believe in Check Exception and like many I do believe they are a design mistake.

Functional Programing and Modern Ways to handle errors

An exception should be used only when you want to blow the program and something hard to recover just happen. In most cases, you should be returning default values or using Optional. These practices will make you code not only easier to read but also more reliable and solid in the long run.

Originally published at http://diego-pacheco.blogspot.com on August 27, 2020.

Brazilian, Software Architect, SWE(Java, Scala, Rust, Go) SOA & DevOps expert, Author. Working with EKS/K8S. diegopacheco.github.io (Opinions on my own)

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store