<p>I have a simple setter method for a property and <code>null</code> is not appropriate for this particular property. I have always been torn in this situation: should I throw an <a href="http://docs.oracle.com/javase/7/docs/api/java/lang/IllegalArgumentException.html" rel="noreferrer"><code>IllegalArgumentException</code></a>, or a <a href="http://docs.oracle.com/javase/7/docs/api/java/lang/NullPointerException.html" rel="noreferrer"><code>NullPointerException</code></a>? From the javadocs, both seem appropriate. Is there some kind of an understood standard?  Or is this just one of those things that you should do whatever you prefer and both are really correct?</p>

[{'answer_id': 3886, 'author': 'Greg Hurlman', 'author_id': 35, 'author_profile': 'https://Stackoverflow.com/users/35', 'pm_score': 9, 'selected': True, 'text': "<p>It seems like an <code>IllegalArgumentException</code> is called for if you don't want <code>null</code> to be an allowed value, and the <code>NullPointerException</code> would be thrown if you were trying to <em>use</em> a variable that turns out to be <code>null</code>.</p>\n"}, {'answer_id': 3890, 'author': 'Jeremy Privett', 'author_id': 560, 'author_profile': 'https://Stackoverflow.com/users/560', 'pm_score': 4, 'selected': False, 'text': "<p>If it's a <code>setter</code> method and <code>null</code> is being passed to it, I think it would make more sense to throw an <code>IllegalArgumentException</code>. A <code>NullPointerException</code> seems to make more sense in the case where you're attempting to actually use the <code>null</code>.</p>\n\n<p>So, if you're using it and it's <code>null</code>, <code>NullPointer</code>. If it's being passed in and it's <code>null</code>, <code>IllegalArgument</code>.</p>\n"}, {'answer_id': 6358, 'author': 'Mark Renouf', 'author_id': 758, 'author_profile': 'https://Stackoverflow.com/users/758', 'pm_score': 6, 'selected': False, 'text': '<p>I tend to follow the design of JDK libraries, especially Collections and Concurrency (Joshua Bloch, Doug Lea, those guys know how to design solid APIs). Anyway, many APIs in the JDK pro-actively throws <code>NullPointerException</code>. </p>\n\n<p>For example, the Javadoc for <code>Map.containsKey</code> states:</p>\n\n<blockquote>\n  <p>@throws NullPointerException if the key is null and this map\n    does not permit null keys (optional).</p>\n</blockquote>\n\n<p>It\'s perfectly valid to throw your own NPE. The convention is to include the parameter name which was null in the message of the exception. </p>\n\n<p>The pattern goes:</p>\n\n<pre><code>public void someMethod(Object mustNotBeNull) {  \n    if (mustNotBeNull == null) {  \n        throw new NullPointerException("mustNotBeNull must not be null");  \n    }  \n}\n</code></pre>\n\n<p>Whatever you do, don\'t allow a bad value to get set and throw an exception later when other code attempts to use it. That makes debugging a nightmare. You should always the follow the "fail-fast" principle.</p>\n'}, {'answer_id': 7770, 'author': 'jassuncao', 'author_id': 1009, 'author_profile': 'https://Stackoverflow.com/users/1009', 'pm_score': -1, 'selected': False, 'text': '<p>If you choose to throw a NPE and you are using the argument in your method, it might be redundant and expensive to explicitly check for a null. I think the VM already does that for you.</p>\n'}, {'answer_id': 8132, 'author': 'Claude Houle', 'author_id': 244, 'author_profile': 'https://Stackoverflow.com/users/244', 'pm_score': 3, 'selected': False, 'text': '<p>The accepted practice if to use the <em>IllegalArgumentException( String message )</em> to declare a parameter to be invalid and give as much detail as possible... So to say that a parameters was found to be null while exception non-null, you would do something like this:</p>\n\n<pre><code>if( variable == null )\n    throw new IllegalArgumentException("The object \'variable\' cannot be null");\n</code></pre>\n\n<p>You have virtually no reason to implicitly use the "NullPointerException". The NullPointerException is an exception thrown by the Java Virtual Machine when you try to execute code on null reference (Like <em>toString()</em>).</p>\n'}, {'answer_id': 8160, 'author': 'GaryF', 'author_id': 1035, 'author_profile': 'https://Stackoverflow.com/users/1035', 'pm_score': 7, 'selected': False, 'text': '<p>The standard is to throw the <code>NullPointerException</code>. The generally infallible "Effective Java" discusses this briefly in Item 42 (first edition), Item 60 (second edition), or Item 72 (third edition) "Favor the use of standard exceptions":</p>\n\n<blockquote>\n  <p>"Arguably, all erroneous method\n  invocations boil down to an illegal\n  argument or illegal state, but other\n  exceptions are standardly used for\n  certain kinds of illegal arguments and\n  states. If a caller passes null in\n  some parameter for which null values\n  are prohibited, convention dictates\n  that NullPointerException be thrown\n  rather than IllegalArgumentException."</p>\n</blockquote>\n'}, {'answer_id': 13262, 'author': 'martinatime', 'author_id': 1353, 'author_profile': 'https://Stackoverflow.com/users/1353', 'pm_score': -1, 'selected': False, 'text': '<p>The definitions from the links to the two exceptions above are\nIllegalArgumentException: Thrown to indicate that a method has been passed an illegal or inappropriate argument. \nNullPointerException: Thrown when an application attempts to use null in a case where an object is required.</p>\n\n<p>The big difference here is the IllegalArgumentException is supposed to be used when checking that an argument to a method is valid. NullPointerException is supposed to be used whenever an object being "used" when it is null.</p>\n\n<p>I hope that helps put the two in perspective.</p>\n'}, {'answer_id': 22074, 'author': 'Allain Lalonde', 'author_id': 2443, 'author_profile': 'https://Stackoverflow.com/users/2443', 'pm_score': 3, 'selected': False, 'text': "<p>Couldn't agree more with what's being said.  Fail early, fail fast.  Pretty good Exception mantra. </p>\n\n<p>The question about which Exception to throw is mostly a matter of personal taste.  In my mind IllegalArgumentException seems more specific than using a NPE since it's telling me that the problem was with an argument I passed to the method and not with a value that may have been generated while performing the method.</p>\n\n<p>My 2 Cents</p>\n"}, {'answer_id': 32940, 'author': 'erickson', 'author_id': 3474, 'author_profile': 'https://Stackoverflow.com/users/3474', 'pm_score': -1, 'selected': False, 'text': '<p>If it\'s a "setter", or somewhere I\'m getting a member to use later, I tend to use IllegalArgumentException.</p>\n\n<p>If it\'s something I\'m going to use (dereference) right now in the method, I throw a NullPointerException proactively. I like this better than letting the runtime do it, because I can provide a helpful message (seems like the runtime could do this too, but that\'s a rant for another day).</p>\n\n<p>If I\'m overriding a method, I use whatever the overridden method uses.</p>\n'}, {'answer_id': 45518, 'author': 'Community', 'author_id': -1, 'author_profile': 'https://Stackoverflow.com/users/-1', 'pm_score': 3, 'selected': False, 'text': "<p>In general, a developer should <strong>never</strong> throw a NullPointerException. This exception is thrown by the runtime when code attempts to dereference a variable who's value is null. Therefore, if your method wants to explicitly disallow null, as opposed to just happening to have a null value raise a NullPointerException, you should throw an IllegalArgumentException.</p>\n"}, {'answer_id': 47710, 'author': 'Jason Cohen', 'author_id': 4926, 'author_profile': 'https://Stackoverflow.com/users/4926', 'pm_score': 9, 'selected': False, 'text': '<p>You should be using <code>IllegalArgumentException</code> (IAE), not <code>NullPointerException</code> (NPE) for the following reasons:</p>\n\n<p>First, the <a href="http://docs.oracle.com/javase/1.5.0/docs/api/java/lang/NullPointerException.html" rel="noreferrer">NPE JavaDoc</a> explicitly lists the cases where NPE is appropriate.  Notice that all of them are thrown <em>by the runtime</em> when <code>null</code> is used inappropriately.  In contrast, the <a href="http://docs.oracle.com/javase/1.5.0/docs/api/java/lang/IllegalArgumentException.html" rel="noreferrer">IAE JavaDoc</a> couldn\'t be more clear: "Thrown to indicate that a method has been passed an illegal or inappropriate argument."  Yup, that\'s you!</p>\n\n<p>Second, when you see an NPE in a stack trace, what do you assume?  Probably that someone dereferenced a <code>null</code>.  When you see IAE, you assume the caller of the method at the top of the stack passed in an illegal value.  Again, the latter assumption is true, the former is misleading.</p>\n\n<p>Third, since IAE is clearly designed for validating parameters, you have to assume it as the default choice of exception, so why would you choose NPE instead?  Certainly not for different behavior -- do you really expect calling code to catch NPE\'s separately from IAE and do something different as a result?  Are you trying to communicate a more specific error message?  But you can do that in the exception message text anyway, as you should for all other incorrect parameters.</p>\n\n<p>Fourth, all other incorrect parameter data will be IAE, so why not be consistent?  Why is it that an illegal <code>null</code> is so special that it deserves a separate exception from all other types of illegal arguments?</p>\n\n<p>Finally, I accept the argument given by other answers that parts of the Java API use NPE in this manner.  However, the Java API is inconsistent with everything from exception types to naming conventions, so I think just blindly copying (your favorite part of) the Java API isn\'t a good enough argument to trump these other considerations.</p>\n'}, {'answer_id': 51213, 'author': 'Will Sargent', 'author_id': 5266, 'author_profile': 'https://Stackoverflow.com/users/5266', 'pm_score': -1, 'selected': False, 'text': "<p>You should throw an IllegalArgumentException, as it will make it obvious to the programmer that he has done something invalid.  Developers are so used to seeing NPE thrown by the VM, that any programmer would not immediately realize his error, and would start looking around randomly, or worse, blame your code for being 'buggy'.</p>\n"}, {'answer_id': 212119, 'author': 'Steve McLeod', 'author_id': 2959, 'author_profile': 'https://Stackoverflow.com/users/2959', 'pm_score': 5, 'selected': False, 'text': '<p>It\'s a "Holy War" style question. In others words, both alternatives are good, but people will have their preferences which they will defend to the death.</p>\n'}, {'answer_id': 247447, 'author': 'Community', 'author_id': -1, 'author_profile': 'https://Stackoverflow.com/users/-1', 'pm_score': -1, 'selected': False, 'text': '<p>In this case, IllegalArgumentException conveys clear information to the user using your API that the " should not be null". As other forum users pointed out you could use NPE if you want to as long as you convey the right information to the user using your API. </p>\n\n<p>GaryF and tweakt dropped "Effective Java" (which I swear by) references which recommends using NPE. And looking at how other good APIs are constructed is the best way to see how to construct your API.</p>\n\n<p>Another good example is to look at the Spring APIs. For example, org.springframework.beans.BeanUtils.instantiateClass(Constructor ctor, Object[] args) has a Assert.notNull(ctor, "Constructor must not be null") line. org.springframework.util.Assert.notNull(Object object, String message) method checks to see if the argument (object) passed in is null and if it is it throws a new IllegalArgumentException(message) which is then caught in the org.springframework.beans.BeanUtils.instantiateClass(...) method.</p>\n'}, {'answer_id': 452516, 'author': 'Jason Fritcher', 'author_id': 56038, 'author_profile': 'https://Stackoverflow.com/users/56038', 'pm_score': 2, 'selected': False, 'text': '<p>I wanted to single out Null arguments from other illegal arguments, so I derived an exception from IAE named NullArgumentException. Without even needing to read the exception message, I know that a null argument was passed into a method and by reading the message, I find out which argument was null. I still catch the NullArgumentException with an IAE handler, but in my logs is where I can see the difference quickly.</p>\n'}, {'answer_id': 1072549, 'author': 'Brian T. Grant', 'author_id': 131137, 'author_profile': 'https://Stackoverflow.com/users/131137', 'pm_score': 3, 'selected': False, 'text': '<p>Apache Commons Lang has a <a href="http://commons.apache.org/lang/apidocs/org/apache/commons/lang/NullArgumentException.html" rel="noreferrer">NullArgumentException</a> that does a number of the things discussed here: it extends IllegalArgumentException and its sole constructor takes the name of the argument which should have been non-null.</p>\n\n<p>While I feel that throwing something like a NullArgumentException or IllegalArgumentException more accurately describes the exceptional circumstances, my colleagues and I have chosen to defer to Bloch\'s advice on the subject.</p>\n'}, {'answer_id': 1871889, 'author': 'Christopher Smith', 'author_id': 60871, 'author_profile': 'https://Stackoverflow.com/users/60871', 'pm_score': 6, 'selected': False, 'text': '<p>Voted up Jason Cohen\'s argument because it was well presented. Let me dismember it step by step. ;-)</p>\n\n<ul>\n<li><p>The <a href="http://docs.oracle.com/javase/7/docs/api/" rel="noreferrer">NPE JavaDoc</a> explicitly says, <em>"other illegal uses of the null object"</em>. If it was just limited to situations where the runtime encounters a null when it shouldn\'t, all such cases could be defined far more succinctly.</p></li>\n<li><p>Can\'t help it if you assume the wrong thing, but assuming encapsulation is applied properly, you really shouldn\'t care or notice whether a null was dereferenced inappropriately vs. whether a method detected an inappropriate null and fired an exception off.</p></li>\n<li><p>I\'d choose <a href="http://docs.oracle.com/javase/7/docs/api/" rel="noreferrer">NPE</a> over <a href="http://docs.oracle.com/javase/7/docs/api/java/lang/IllegalArgumentException.html" rel="noreferrer">IAE</a> for multiple reasons</p>\n\n<ul>\n<li>It is more specific about the nature of the illegal operation</li>\n<li>Logic that mistakenly allows nulls tends to be very different from logic that mistakenly allows illegal values. For example, if I\'m validating data entered by a user, if I get value that is unacceptable, the source of that error is with the end user of the application. If I get a null, that\'s programmer error.</li>\n<li>Invalid values can cause things like stack overflows, out of memory errors, parsing exceptions, etc. Indeed, most errors generally present, at some point, as an invalid value in some method call. For this reason I see IAE as actually the <em>MOST GENERAL</em> of all exceptions under RuntimeException.</li>\n</ul></li>\n<li><p>Actually, other invalid arguments can result in all kinds of other exceptions. <a href="http://docs.oracle.com/javase/7/docs/api/java/net/UnknownHostException.html" rel="noreferrer">UnknownHostException</a>, <a href="http://docs.oracle.com/javase/7/docs/api/java/io/FileNotFoundException.html" rel="noreferrer">FileNotFoundException</a>, a variety of syntax error exceptions, <a href="http://docs.oracle.com/javase/7/docs/api/java/lang/IndexOutOfBoundsException.html" rel="noreferrer">IndexOutOfBoundsException</a>, authentication failures, etc., etc.</p></li>\n</ul>\n\n<p>In general, I feel NPE is much maligned because traditionally has been associated with code that fails to follow the <a href="http://www.martinfowler.com/ieeeSoftware/failFast.pdf" rel="noreferrer">fail fast principle</a>. That, plus the JDK\'s failure to populate NPE\'s with a message string really has created a strong negative sentiment that isn\'t well founded. Indeed, the difference between NPE and IAE from a runtime perspective is strictly the name. From that perspective, the more precise you are with the name, the more clarity you give to the caller.</p>\n'}, {'answer_id': 8196334, 'author': 'MB.', 'author_id': 11961, 'author_profile': 'https://Stackoverflow.com/users/11961', 'pm_score': 7, 'selected': False, 'text': '<p>I was all in favour of throwing <code>IllegalArgumentException</code> for null parameters, until today, when I noticed the <code>java.util.Objects.requireNonNull</code> method in Java 7.  With that method, instead of doing:</p>\n\n<pre><code>if (param == null) {\n    throw new IllegalArgumentException("param cannot be null.");\n}\n</code></pre>\n\n<p>you can do:</p>\n\n<pre><code>Objects.requireNonNull(param);\n</code></pre>\n\n<p>and it will throw a <code>NullPointerException</code> if the parameter you pass it is <code>null</code>.</p>\n\n<p>Given that that method is right bang in the middle of <code>java.util</code> I take its existence to be a pretty strong indication that throwing <code>NullPointerException</code> is "the Java way of doing things".</p>\n\n<p>I think I\'m decided at any rate.</p>\n\n<p>Note that the arguments about hard debugging are bogus because you can of course provide a message to <code>NullPointerException</code> saying what was null and why it shouldn\'t be null.  Just like with <code>IllegalArgumentException</code>.</p>\n\n<p>One added advantage of <code>NullPointerException</code> is that, in highly performance critical code, you could dispense with an explicit check for null (and a <code>NullPointerException</code> with a friendly error message), and just rely on the <code>NullPointerException</code> you\'ll get automatically when you call a method on the null parameter.  Provided you call a method quickly (i.e. fail fast), then you have essentially the same effect, just not quite as user friendly for the developer.  Most times it\'s probably better to check explicitly and throw with a useful message to indicate which parameter was null, but it\'s nice to have the option of changing that if performance dictates without breaking the published contract of the method/constructor.</p>\n'}, {'answer_id': 10195862, 'author': 'Luis Daniel Mesa Velasquez', 'author_id': 1339367, 'author_profile': 'https://Stackoverflow.com/users/1339367', 'pm_score': 2, 'selected': False, 'text': '<p>the dichotomy... Are they non-overlapping? Only non-overlapping parts of a whole can make a dichotomy. As i see it:</p>\n\n<pre><code>throw new IllegalArgumentException(new NullPointerException(NULL_ARGUMENT_IN_METHOD_BAD_BOY_BAD));\n</code></pre>\n'}, {'answer_id': 13311822, 'author': 'Chris Povirk', 'author_id': 28465, 'author_profile': 'https://Stackoverflow.com/users/28465', 'pm_score': 3, 'selected': False, 'text': '<p>Some collections assume that <code>null</code> is rejected using <code>NullPointerException</code> rather than <code>IllegalArgumentException</code>. For example, if you compare a set containing <code>null</code> to a set that rejects <code>null</code>, the first set will call <code>containsAll</code> on the other and catch its <code>NullPointerException</code> -- but not <code>IllegalArgumentException</code>. (I\'m looking at the implementation of <code>AbstractSet.equals</code>.)</p>\n<p>You could reasonably argue that using unchecked exceptions in this way is an antipattern, that comparing collections that contain <code>null</code> to collections that can\'t contain <code>null</code> is a likely bug that really <em>should</em> produce an exception, or that putting <code>null</code> in a collection at all is a bad idea. Nevertheless, unless you\'re willing to say that <code>equals</code> should throw an exception in such a case, you\'re stuck remembering that <code>NullPointerException</code> is required in certain circumstances but not in others. (&quot;IAE before NPE except after \'c\'...&quot;)</p>\n<p>Somewhat similarly, build tools may insert null checks <em>automatically</em>. Notably, Kotlin\'s compiler <a href="https://kotlinlang.org/docs/java-interop.html#null-safety-and-platform-types" rel="nofollow noreferrer">does this</a> when passing a possibly null value to a Java API. And when a check fails, the result is a <code>NullPointerException</code>. So, to give consistent behavior to any Kotlin users and Java users that you have, you\'d need to use <code>NullPointerException</code>.</p>\n'}, {'answer_id': 13312050, 'author': 'Chris Povirk', 'author_id': 28465, 'author_profile': 'https://Stackoverflow.com/users/28465', 'pm_score': 3, 'selected': False, 'text': '<p>Throwing an exception that\'s exclusive to <code>null</code> arguments (whether <code>NullPointerException</code> or a custom type) makes automated <code>null</code> testing more reliable. This automated testing can be done with reflection and a set of default values, as in <a href="http://code.google.com/p/guava-libraries/" rel="noreferrer">Guava</a>\'s <a href="http://code.google.com/p/guava-libraries/source/browse/guava-testlib/src/com/google/common/testing/NullPointerTester.java" rel="noreferrer"><code>NullPointerTester</code></a>. For example, <code>NullPointerTester</code> would attempt to call the following method...</p>\n\n<pre><code>Foo(String string, List&lt;?&gt; list) {\n  checkArgument(string.length() &gt; 0);\n  // missing null check for list!\n  this.string = string;\n  this.list = list;\n}\n</code></pre>\n\n<p>...with two lists of arguments: <code>"", null</code> and <code>null, ImmutableList.of()</code>. It would test that each of these calls throws the expected <code>NullPointerException</code>. For this implementation, passing a <code>null</code> list does <em>not</em> produce <code>NullPointerException</code>. It does, however, happen to produce an <code>IllegalArgumentException</code> because <code>NullPointerTester</code> happens to use a default string of <code>""</code>. If <code>NullPointerTester</code> expects only <code>NullPointerException</code> for <code>null</code> values, it catches the bug. If it expects <code>IllegalArgumentException</code>, it misses it.</p>\n'}, {'answer_id': 14104551, 'author': 'Sascha Baumeister', 'author_id': 1940048, 'author_profile': 'https://Stackoverflow.com/users/1940048', 'pm_score': 3, 'selected': False, 'text': '<p>Actually, the question of throwing IllegalArgumentException or NullPointerException is in my humble view only a "holy war" for a minority with an incomlete understanding of exception handling in Java. In general, the rules are simple, and as follows:</p>\n\n<ul>\n<li>argument constraint violations must be indicated as fast as possible (-> fast fail), in order to avoid illegal states which are much harder to debug</li>\n<li>in case of an invalid null pointer for whatever reason, throw NullPointerException</li>\n<li>in case of an illegal array/collection index, throw ArrayIndexOutOfBounds</li>\n<li>in case of a negative array/collection size, throw NegativeArraySizeException</li>\n<li>in case of an illegal argument that is not covered by the above, and for which you don\'t have another more specific exception type, throw IllegalArgumentException as a wastebasket</li>\n<li>on the other hand, in case of a constraint violation WITHIN A FIELD that could not be avoided by fast fail for some valid reason, catch and rethrow as IllegalStateException or a more specific checked exception. Never let pass the original NullPointerException, ArrayIndexOutOfBounds, etc in this case!</li>\n</ul>\n\n<p>There are at least three very good reasons against the case of mapping all kinds of argument constraint violations to IllegalArgumentException, with the third probably being so severe as to mark the practice bad style:</p>\n\n<p>(1) A programmer cannot a safely assume that all cases of argument constraint violations result in IllegalArgumentException, because the large majority of standard classes use this exception rather as a wastebasket if there is no more specific kind of exception available. Trying to map all cases of argument constraint violations to IllegalArgumentException in your API only leads to programmer frustration using your classes, as the standard libraries mostly follow different rules that violate yours, and most of your API users will use them as well!</p>\n\n<p>(2) Mapping the exceptions actually results in a different kind of anomaly, caused by single inheritance: All Java exceptions are classes, and therefore support single inheritance only. Therefore, there is no way to create an exception that is truly say both a NullPointerException and an IllegalArgumentException, as subclasses can only inherit from one or the other. Throwing an IllegalArgumentException in case of a null argument therefore makes it harder for API users to distinguish between problems whenever a program tries to programmatically correct the problem, for example by feeding default values into a call repeat!</p>\n\n<p>(3) Mapping actually creates the danger of bug masking: In order to map argument constraint violations into IllegalArgumentException, you\'ll need to code an outer try-catch within every method that has any constrained arguments. However, simply catching RuntimeException in this catch block is out of the question, because that risks mapping documented RuntimeExceptions thrown by libery methods used within yours into IllegalArgumentException, even if they are no caused by argument constraint violations. So you need to be very specific, but even that effort doesn\'t protect you from the case that you accidentally map an undocumented runtime exception of another API (i.e. a bug) into an IllegalArgumentException of your API. Even the most careful mapping therefore risks masking programming errors of other library makers as argument constraint violations of your method\'s users, which is simply hillareous behavior!</p>\n\n<p>With the standard practice on the other hand, the rules stay simple, and exception causes stay unmasked and specific. For the method caller, the rules are easy as well:\n- if you encounter a documented runtime exception of any kind because you passed an illegal value, either repeat the call with a default (for this specific exceptions are neccessary), or correct your code\n- if on the other hand you enccounter a runtime exception that is not documented to happen for a given set of arguments, file a bug report to the method\'s makers to ensure that either their code or their documentation is fixed.</p>\n'}, {'answer_id': 30663317, 'author': 'leo', 'author_id': 4586938, 'author_profile': 'https://Stackoverflow.com/users/4586938', 'pm_score': 2, 'selected': False, 'text': '<p>According to your scenario, <code>IllegalArgumentException</code> is the best pick, because <code>null</code> is not a valid value for your property.</p>\n'}, {'answer_id': 31004679, 'author': 'Nitesh Soomani', 'author_id': 5039151, 'author_profile': 'https://Stackoverflow.com/users/5039151', 'pm_score': 2, 'selected': False, 'text': '<p><code>NullPointerException</code> thrown when attempting to access an object with a reference variable whose current value is <code>null</code>.</p>\n\n<p><code>IllegalArgumentException</code> thrown when a method receives an argument formatted differently than the method expects.</p>\n'}, {'answer_id': 39013552, 'author': 'vijay', 'author_id': 6729598, 'author_profile': 'https://Stackoverflow.com/users/6729598', 'pm_score': -1, 'selected': False, 'text': '<p>Ideally runtime exceptions should not be thrown. A checked exception(business exception) should be created for your scenario. Because if either of these exception is thrown and logged, it misguides the developer while going through the logs. Instead business exceptions do not create that panic and usually ignored while troubleshooting logs.</p>\n'}, {'answer_id': 39658107, 'author': 'Ben Seidel', 'author_id': 5336361, 'author_profile': 'https://Stackoverflow.com/users/5336361', 'pm_score': 3, 'selected': False, 'text': '<p>As a subjective question this should be closed, but as it\'s still open:</p>\n\n<p>This is part of the internal policy used at my previous place of employment and it worked really well. This is all from memory so I can\'t remember the exact wording. It\'s worth noting that they did not use checked exceptions, but that is beyond the scope of the question. The unchecked exceptions they did use fell into 3 main categories.</p>\n\n<p>NullPointerException: Do not throw intentionally. NPEs are to be thrown only by the VM when dereferencing a null reference. All possible effort is to be made to ensure that these are never thrown. @Nullable and @NotNull should be used in conjunction with code analysis tools to find these errors.</p>\n\n<p>IllegalArgumentException: Thrown when an argument to a function does not conform to the public documentation, such that the error can be identified and described in terms of the arguments passed in. The OP\'s situation would fall into this category.</p>\n\n<p>IllegalStateException: Thrown when a function is called and its arguments are either unexpected at the time they are passed or incompatible with the state of the object the method is a member of.</p>\n\n<p>For example, there were two internal versions of the IndexOutOfBoundsException used in things that had a length. One a sub-class of IllegalStateException, used if the index was larger than the length. The other a subclass of IllegalArgumentException, used if the index was negative. This was because you could add more items to the object and the argument would be valid, while a negative number is never valid.</p>\n\n<p>As I said, this system works really well, and it took someone to explain why the distinction is there: "Depending on the type of error it is quite straightforward for you to figure out what to do. Even if you can\'t actually figure out what went wrong you can figure out where to catch that error and create additional debugging information."</p>\n\n<p>NullPointerException: Handle the Null case or put in an assertion so that the NPE is not thrown. If you put in an assertion is just one of the other two types. If possible, continue debugging as if the assertion was there in the first place.</p>\n\n<p>IllegalArgumentException: you have something wrong at your call site. If the values being passed in are from another function, find out why you are receiving an incorrect value. If you are passing in one of your arguments propagate the error checks up the call stack until you find the function that is not returning what you expect.</p>\n\n<p>IllegalStateException: You have not called your functions in the correct order. If you are using one of your arguments, check them and throw an IllegalArgumentException describing the issue. You can then propagate the cheeks up against the stack until you find the issue.</p>\n\n<p>Anyway, his point was that you can only copy the IllegalArgumentAssertions up the stack. There is no way for you to propagate the IllegalStateExceptions or NullPointerExceptions up the stack because they had something to do with your function.</p>\n'}]
['https://Stackoverflow.com/questions/3881', 'https://Stackoverflow.com', 'https://Stackoverflow.com/users/122/']