Effective Java: Favor The Use of Standard Exceptions

Effective Java Review (90 Part Series)

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. One such area of the standard library in Java that can be useful to understand is the built-in exception types.

Let’s look at some of the most commonly used exception types and discuss their uses:

IllegalArgumentException: This exception is generally thrown when a caller of a function provides an inappropriate value. This could be something like a negative value for the number of iterations of some algorithm.

IllegalStateException: This exception is used if, when a method is called, the state of the object is not valid for that operation. Potentially you have a filehandle and you call read before it has been opened.

NullPointerException: This exception only has one direct use by a developer and that is when a null value is passed in as an argument and that is not an acceptable value. In this way, it can be looked at as being used as a specialization of the IllegalArgumentException. Outside of this use case, I would hesitate to use this exception type.

IndexOutOfBoundsException: Another exception type that can be looked at as a specialization of the IllegalArgumentException except in this case a user of an API is passing in an index that is out of the calling collection.

ConcurrentModificationException: I’ll be honest, I haven’t found myself needing to use this exception in my own code but maybe I have just not been working in the correct domains to need it. This exception is thrown when a particular object is modified by two different threads when the object is not meant to be used concurrently. This exception is mostly a hint to the caller that something funny is happening as reliably detecting a concurrent modification to an object is difficult.

UnsupportedOperationException: Another exception type that gets less usage. This exception type is used when there is some function in an object’s API that is not supported. I say this exception type is used fairly rarely because usually you want to be implementing all of your methods. A valid use of this exception though may be a collection that implements the Collection interface but is an unmodifiable collection. Thus when the add method is called from the interface it would throw this exception type. If you feel the need to use this exception type, do take a moment to stop and think about whether you are implementing the correct interface and whether it is reasonable that you are not implementing a particular function.

Some built-in exception types are discouraged from direct use. These would be Exception, RuntimeException, Throwable, and Error. The reason being is that these types largely serve the purpose of an abstract class in that they are a jumping-off point for more specialized types. When you use them directly you are making the handler of these exceptions life much more difficult because of how generic the types are.

Many other built-in exception types in Java can be used for particular situations. Feel free to leverage them when the situation arises but do consider not only the name of the exception but the details and semantics outlined in the JavaDoc of the exception type. If your particular use case does not fit those semantics, think twice before the reuse of the exception. If there is simply more information you would like to add to an exception, a good middle ground would be to extend that exception type and provide your additional data on that subclass.

Sometimes two exception types seem like they could fit the use cases. In cases such as this, you will need to use your best discretion to decide which one to use. For example, let us consider the case where a function takes in a parameter of how many items to pull out of a bag. If a caller proves 5 as the number of items to pull from the bag and there are only 3 items left, what exception makes sense? On the one hand, IllegalArgumentException could be argued to be the correct one as the argument they provided was not valid. On the other hand, it could be argued that IllegalStateException would be the correct one as the state of the object could be thought of as the problem and if there were more things in the bag it would have succeeded. The decision criteria Effective Java sets out, which I think is solid logic, is to use IllegalStateException if no parameter value would be construed as valid, and IllegalArgumentException if that particular argument is invalid within a set of valid arguments.

Having even a shallow exposure to different built-in exception types can be quite beneficial to your code. It can save you time and effort from reinventing the wheel, make your code much easier to understand for future developers as they are already familiar with the types you are using, and even (in extreme cases) help the JVM load a little faster and use less memory in that fewer classes need to be loaded.

Effective Java Review (90 Part Series)

原文链接：Effective Java: Favor The Use of Standard Exceptions

文章版权声明 1、本网站名称：拾光赋
2、本站永久网址：https://www.blogs.ink
3、本网站的文章部分内容可能来源于网络，仅供大家学习与参考，如有侵权，请联系站长QQ：805375623进行删除处理。
4、本站一切资源不代表本站立场，并不代表本站赞同其观点和对其真实性负责。
5、本站一律禁止以任何方式发布或转载任何违法的相关信息，访客发现请向站长举报
6、本站资源大多存储在云盘，如发现链接失效，请联系我们我们会第一时间更新。

THE END