Recently I was working on a project where we were working with a third party in order to process different Office files. This third-party had both a production tenant as well as a development tenant as can be common with these types of integrations. The development tenant was much less stable than the production tenant and, at least it felt like, it would go down quite often. At this point it was just a gut feel from our interactions on and off with the service so we wanted to quantify it. As we considered ways we could check whether the…
Even after an object throws an exception it is expected and desirable that the object is still in a valid state. Unless the exception that is thrown is a fatal exception the application will keep moving forward and thus leaving the object in an invalid state is just asking for further issues. This being the case, we should strive to leave objects in a valid state even after an exception is thrown.
Let us consider some ways that we can accomplish leaving our objects in a valid state.
The first of these options is to create immutable objects. This greatly…
Often when we are analyzing a failure of some code all we are left with is the logs that are left behind. Seeing as this is the case, we want to give ourselves the best chance of success. When a program fails the system will automatically output the exception’s stack trace which includes the value that gets returned from the toString method of the exception. This message serves as a core capability in explaining the state of the system and particularly the exception to the future investigators. …
Documentation is critical for quickly understanding a class and its methods. Exceptions, both checked and unchecked, are part of the contract of a method and thus should be properly documented to allow users of your code to quickly understand how your code behaves.
Part of what makes good documentation is that it is very specific. While it is not a lie to document that a method throws Exception or even Throwable it isn't useful. We should be striving to throw (and by extension document) the most specific exception type possible. …
Much of Effective Java focuses on building a clean, understandable API and how that is the foundation of a great library. Part of the API of a class is any exceptions it may throw up the stack both checked (where it becomes part of the signature) or unchecked. As writers of the code, it is our responsibility to make sure that there aren’t any surprises or anything shocking from this API. One of the ways this can happen is with the exposure of an exception that doesn’t make sense for the class we are writing.
A potential example of a…
Every once in a while as a developer you find yourself stepping, and falling, into a much deeper rabbit hole than you would expect. I recently had one of these experiences as I have dug into the world of unique identifiers. It is this rabbit hole that I would like to take you down for a bit as well. Unique identifiers are everywhere in our code and our data storage and through better understanding what they are and the trade-offs between them we can make more educated decisions in our day-to-day work.
Where we began:
Historically a lot of software has used incrementing…
As a developer becomes more proficient in a language one of the significant things that makes them more successful is a solid understanding of the standard library of the language. Through knowing what is available out of the box and how to use it these developers can leverage those existing solutions and focus on solving the real problems at hand. In addition to greater efficiency for the original author of the code, future readers of the code benefit from the use of familiar APIs which can improve readability and maintainability. …
Many developers are not fans of checked exceptions. Effective Java argues that this doesn’t need to be the case. The defining feature of a checked exception is forcing the caller to handle the exception either by catching it or by passing the exception up the call stack via its signature.
Why does being forced to handle checked exceptions bother developers though? I would suggest that it is because they don’t know how to handle the exception. Because of this, the compiler forces you to handle it puts the developer in a tough position where no choice feels correct. This is…
This chapter takes on describing when which type of Throwables should be thrown. The two main Throwable types we mostly interact with are checked and unchecked exceptions. The major difference between the two being that checked exceptions are part of method signatures which forces the caller to handle the checked in some way (either catching the exception or passing the exception up the call stack). The question is, when should you use which exception type.
Effective Java suggests the use cases break down as the following. If an exception is recoverable you should use a checked exception and if it…
At some point in your coding career you may be unlucky enough to encounter code that looks somewhat like the following:
try {
int i = 0;
while (true) {
items[i++].process();
}
} catch (ArrayIndexOutOfBoundsException ignored) {
}Likely what this code is doing doesn’t immediately jump out at you, especially compared to a similar function that performs the same function written like this:
for (Item item : items) {
item.process();
}Not only is the first function more code, it is harder to grok and actually less performant. The unfortunate thing is that apparently some developers that write code…
