CODEWITHSUNDEEP
javaandroid
brandall
brandall

Reputation: 6144

When is the right time to throw a RuntimeException?

I'm developing a library for Android, which I intend to open source and naturally I want to tick all of the boxes before I publish it - so users are suitably impressed with my code. Ahem.

As with many libraries, there are certain basic configurations necessary in order for the library to function.

public static final String API_KEY = "your_api_key_here";

In the above instance, when a user passes their API key to the library, I'm putting a simple string match in for "your_api_key_here" and if it matches, I'm going to throw a RuntimeException, as they quite simply haven't read the basic instructions and I want their app to die.

Is this a valid use of a RuntimeException? If it isn't, then in Java what is?

EDIT - My motivation for posting this is due to this post, where the OP is lynched by shouts of "why!?" for asking how to throw one.

ANSWER - In this instance, it seems to be more a matter of preference than right or wrong either way - at least no one has so far objected. This scenario should only occur during the testing phase for a developer and never in production. If this wasn't the case, I wouldn't have chosen an uncaught exception.

I've marked an answer as correct due to the most upvotes and following @mech's comment below, I have created a custom ReadTheDocumentationException which provides a suitably persuasive message.

Upvotes: 2

Views: 229

Answers (3)

Qandeel Abbassi
Qandeel Abbassi

Reputation: 999

I think you should use illegal argument exception which is subclass of java.lang.RuntimeException . You can do something like this

if(API_KEY.equals("your_api_key_here"))
    throw new IllegalArgumentException("you message here");

For more info see this

Upvotes: 7

Doug Stevenson
Doug Stevenson

Reputation: 317712

It sounds like part of your question deals with what is the proper use of RuntimeException, and partly deals with how your library should behave if misconfigured. I'll deal with mostly the former.

In Java, there are two types of exceptions, checked and unchecked.

RuntimeException and all of its subclasses are "unchecked" exceptions, meaning there is no requirement from the compiler to catch them. You can use these to crash your process if something is very wrong. The caller can still catch and handle them on their own, so be prepared that the caller may continue to call into your lib incorrectly.

Exception and all of its subclasses (except RuntimeException) are "checked", meaning that the compiler requires the caller to catch them or declare in a method declaration that it could be thrown. You use this in cases where you expect the caller to try to recover from whatever condition caused the exception to be thrown.

In your case, you can throw a RuntimeException with a meaningful message, or a custom subclass of RuntimeException with a message to indicate to the caller exactly what went wrong and how to remedy it. It doesn't really matter what you choose, but many people choose to subclass for clarity. I'd just make sure that the exception is never thrown by surprise in order to have clear rules for engagement for your lib.

Upvotes: 2

Mussa
Mussa

Reputation: 1499

You should create your own exception by extending RuntimeException or any other Exception. IllegalStateException would work for a case when someone terribly misbehave.

Upvotes: 3

Related Questions