开发者

What exception to throw?

开发者 https://www.devze.com 2023-01-17 15:57 出处:网络
I have a function which calculates the mean of a list passed as an argument. I would like to know which of Java exception should I throw when I try to c开发者_如何学JAVAompute the mean of a list of si

I have a function which calculates the mean of a list passed as an argument. I would like to know which of Java exception should I throw when I try to c开发者_如何学JAVAompute the mean of a list of size 0.

public double mean (MyLinkedList<? extends Number> list)
{
    if (list.isEmpty())
        throw new ????????; //If I am not mistaken Java has some defined exception for this case

    //code goes here
}

Thanks.


You can throw a new IllegalArgumentException().

Thrown to indicate that a method has been passed an illegal or inappropriate argument.

Just don't forget to pass a clear message as a first argument. This will really help you to understand what happend.

For example "Can't use mean on an empty List".


The question to ask yourself first is whether you should be throwing at all and then, if so, whether it should be a checked or unchecked exception.

Unfortunately, there's no industry best practice on deciding these things, as shown by this StackOverflow answer:

In Java, when should I create a checked exception, and when should it be a runtime exception?

Nevertheless, there are some key considerations:

  • Your design/vision for how this method is supposed to work (Is it reasonable/normal for the method to be called with 0-size list)?

  • Consistency with other methods in the class/package

  • Compliance with your applicable coding standard (if any)

My opinion:

  • Return Double.NAN or 0 If calling the method with a 0-size list is reasonable/expected/normal, I'd consider returning Double.NAN or 0 if 0 is appropriate for your problem domain.

  • Throw anIllegalArgumentException If my design says that checking for an empty List is strongly the responsibility of the caller and the documentation for the method is going to clearly state that it is the responsibility of the caller, then I'd use the standard unchecked IllegalArgumentException.

  • Throw a custom checked exception If the method is part of a statistics package or library where several statistics functions need to deal with an possible empty data set, I'd think this is an exception condition that is part of the problem domain. I'd create a custom (probably checked) exception (e.g. EmptyDataSetException) to be part of the class/package/library and use it across all applicable methods. Making it a checked exceptions helps remind the client to consider how to handle the condition.


You should create a new class that extends Exception and provides details specific to your error. For example you could create a class called EmptyListException that contains the details regarding your error. This could be a very simple exception class that takes no constructor arguments but maybe calls super("Cannot generate mean for an empty list"); to provide a custom message to the stack trace.

A lot of times this isn't done enough...one of my most hated code smells is when developers use a generic exception (even sometimes Exception itself) and pass a string message into the constructor. Doing this is valid but makes the jobs of those implementing your code much harder since they have to catch a generic exception when really only a few things could happen. Exceptions should have the same hierarchy as objects you use for data with each level providing more specific details. The more detailed the exception class, the more detailed and helpful the stack trace is.

I've found this site: Exceptional Strategies to be very useful when creating Exceptions for my applications.


IllegalArgumentException


How about NoSuchElementException. Although IllegalArgumentException might be better.


How about an ArithmeticException - the same as the runtime throws.


Are you currently throwing any other exceptions (or planning to?) Any of the previously mentioned exceptions are fine, or just create your own. The most important thing is propagating the message of what went wrong.

If there's a chance the 'catcher' of the exception might re-throw it, than you may want to investigate any other exceptions the 'catcher' might also throw.


I am not convinced you should be throwing an exception there at all; the average of "nothing" is "nothing" or 0 if you will. If the set is empty, you should simply return 0.

If you really MUST throw an exception, then IllegalStateException or IllegalArgumentException are your best choices.

0

精彩评论

暂无评论...
验证码 换一张
取 消