I use assertions in Java in a standard way, having them turned on in my IDE. So they are not part of production release. Lately I have been seeing code examples with throw new AssertionError() and I started thinking about the situation where AssertionError should be used instead of assertion.
My guess is that main difference is the optionality of asserts so they don't slow down the production performance and so they can occur quite often in the code, but fixing hardly reproducible bugs reported from users is harder.
For AssertionError, the exact opposite applies.
I also find AssertionError more practical in places in code where the execution should not get, instead of using assert false //We should not be here. Especially if the return value is required. For example:
int getFoo(AnEnum a){
if (a == AnEnum.ONE)
return bar();
else if (a == AnEnum.TWO)
return SOME_VALUE;
//else
assert false; //throw new AssertionError();
return -1; //not necessary when usin AssertionError
}
Is my reasoning correct?
What are the other differences/use cases/best practices/limitations
of either approach?
In regards to providing a description in the AssertionError - Should it be provided or is the mere fact that it is an Error (and
of assertion type) enough to be more or less sure that stack trace
will be provided in case of found bugs?
In the technote "Programming With Assertions: Control Flow Invariants" the following code is given:
void foo() {
for (...) {
if (...)
return;
}
assert false; // Execution should never reach this point!
}
But the following note is given as well:
Note: Use this technique with discretion. If a statement is unreachable as defined in the Java Language Specification, you will get a compile time error if you try to assert that it is not reached. Again, an acceptable alternative is simply to throw an AssertionError.
You may not expect an AssertionError to be thrown when assertions are turned off. As AssertionError constructors are public, and since there is likely no substitution for AssertionError(String message, Throwable cause), I guess that you should expect them even if they are turned off.
Throwing an AssertionError on unreachable code (i.e. without any real expression to be evaluated) will never slow down the code, as Jon Skeet suggested, so it won't hurt with regards to performance.
So in the end throwing the AssertionError seems OK.
I would advise against throwing AssertionErrors directly. If you choose to rely on AssertionErrors for checking invariants, pre/post conditions, state conditions, etc. you're still better off using regular assertions with the "-ea" flag turned on in production as well.
The reason is that the assertions mechanism (other than being optimized at the compiler level) gives you a chance to turn on or off all assertions at once. Even if you can't think of a reason to do that now, if you come across a reason in the future, just consider that you'll have to go over all your throw new AssertionError(...) type code and surround it with a nasty if clause. You get the picture.
Just as you wouldn't want a magic number hard coded into many places in your code, and would probably use a constant instead, you shouldn't infect your code with many duplications (i.e. the throw new AssertionError(...) part).
Another word about assertions though. I believe that you should think twice before relying on assertion errors in production code. The reason is that an AssertionError is very generic. It has a message and a cause, but that's pretty much it.
Consider instead using specific RuntimeException subclasses that will convey more information both by being of a specific class more related to the problem, as well as by carrying actual data related to the problem.
As a simple example, consider a case you mentioned in your question where there's some part of the code that you don't expect to reach. An assertion or an AssertionError would convey the fact that you reached some unexpected code, but not much more. Using a specific RuntimeException could also deliver the state of the local variables and parameters of the method at that point in time. You could argue that this is doable with setting the message of the assertion or AssertionError to contain this information, but this does not work when using automatic error logging/handling mechanisms. Such mechanisms can handle unexpected behaviors using the visitor pattern on the different sub classes of RuntimeException you're using to check unexpected behavior (by handle I also mean fail-fast, not necessarily recovery).
Related
In the JLS8, chapter "Exceptions" (here), I saw that:
Explicit use of throw statements provides an alternative to the
old-fashioned style of handling error conditions by returning funny
values, such as the integer value -1 where a negative value would not
normally be expected. Experience shows that too often such funny
values are ignored or not checked for by callers, leading to programs
that are not robust, exhibit undesirable behavior, or both.
Actually, I'm not clear about 2 issues following:
(1) "such as the integer value -1 where a negative value would not normally be expected", why "a negative value would not normally be expected"? Follow my knowledge, we often use return value "-1" for an error, abnormal event,... or something "not good".
(2) "Experience shows that too often such funny values are ignored or not checked for by callers, leading to programs that are not robust, exhibit undesirable behavior, or both.". What "funny values are ignored or not checked for by callers, leading to programs that are not robust, exhibit undesirable behavior, or both" means? I don't understant this issue...Please help me to clarify and (if yes) give me an example to demonstrate
Thank you so much
A common example is: people not checking the contents of a string, but blindly calling indexOf() - and not taking into account that the "thing searched for" isn't in that string, so the returned result is -1.
At least when using checked exception the programmer must do something about a potential exception thrown from some code that his code is using. For return values, you can completely ignore them - just a bit easier therefore.
On the other hand, many people argue that the idea of checked exception didn't live up to its promise - and are therefore advocating the usage of unchecked exceptions. Or alternatively, as companies such as google propose: the usage of more sophisticated "return value classes".
Long story short:
by the nature of the language exceptions should be seen as the primary mean to communicate severe exceptional conditions
but that doesn't mean that using numeric return codes is not possible or completely discouraged.
Please help me to clarify and (if yes) give me an example to demonstrate:
For example Class.getResourceAsStream(String) returns null if it cannot find the resource, rather than throwing an exception. This is clearly documented in the javadocs.
However, lots of people don't read the documentation, and don't check the result of a getResourceAsStream call. As a result, when the resource is missing, they use the null and get an unexpected NullPointerException.
Another common example is ServletRequest.getParameter(String).
If you analysed the NPE Q's on StackOverflow, you would find that a significant number of them are caused by people not checking the results of the above two methods. (If you don't believe me, the raw questions are available for you to analyse!)
Why using error code (such as -1) is not efficient than using exception?
The text you quoted doesn't say that. And it is probably not true. In fact, the using an error code is (classically) more efficient in many cases. However, with recent JIT compiler improvements, the overheads of exceptions and exception handling have been significantly reduced for typical use-cases.
Summary:
People are lazy. But you knew that!
People are careless. But you knew that!
APIs that require people to check returned values are less robust than those that throw (checked) exceptions ... because people write code that doesn't check return codes. Why? Because people are lazy, careless or both!
Admittedly, there are pragmatic reasons not to throw exceptions. However it is a trade-off of robustness vs efficiency vs forcing the programmer to deal with checked exceptions.
The text you quoted is not trying to tell you use exceptions always. Rather it is explaining the reasons that exceptions are part of the Java language.
You may disagree, but ... frankly ... it is not a topic that is worth debating. Exceptions (checked / unchecked, etc) are so hard-baked into the Java language that it would be impossible to change.
(1) "such as the integer value -1 where a negative value would not normally be expected", why "a negative value would not normally be expected"?
It is a proven fact (see below) that people don't always check return values.
Follow my knowledge, we often use return value "-1" for an error, abnormal event,... or something "not good".
True. And exceptions provide an alternative.
What "funny values are ignored or not checked for by callers
'Funny values' such as -1. There are examples posted here every hour of every day.
leading to programs that are not robust, exhibit undesirable behavior, or both" means?
It means that programs that ignore 'funny values' aren't robust or exhibit undesirable behaviour ... and give rise to trivial questions on this site.
I don't understand this issue...Please help me to clarify and (if yes) give me an example to demonstrate.
Try this search for hundreds of examples.
When a method return an int, the caller have to check if it is an error code. But if here is no expected range of returned value, how could you specify an error signal value?
Let us say what "error code" should a parseInt method return?
And if the caller "forgets" to check the returned value, the error could go unnoticed.
However if an exception is declared, the caller must check and handle it, by catching it or declaring i in throws...
I'm reading the source of XWalkUIClientInternal and I ran into the following code:
switch(type) {
case JAVASCRIPT_ALERT:
return onJsAlert(view, url, message, result);
case JAVASCRIPT_CONFIRM:
return onJsConfirm(view, url, message, result);
case JAVASCRIPT_PROMPT:
return onJsPrompt(view, url, message, defaultValue, result);
case JAVASCRIPT_BEFOREUNLOAD:
// Reuse onJsConfirm to show the dialog.
return onJsConfirm(view, url, message, result);
default:
break;
}
assert(false);
return false;
I've never really seen this technique nor really thought about it before, but I guess this essentially means "this is unreachable code and should not happen ever", and crash the app no matter what. Although technically you can do that with a Throwable, as long as it's not caught.
So my question is, which one is better and why, assert(false) or throwing a RuntimeException, or maybe an Error?
The biggest difference between
assert false;
(The parenthesis are not needed, assert is not a function but a statement.) and
throw new RuntimeException();
is that the assertion can be disabled. Actually, it is disabled by default unless the JVM is started with the -ea (“enable assertions”) flag. If assertions are enabled, assert false will unconditionally throw an AssertionError which derives from Error. But since assertions can be disabled, there are two problems,
the error might go undetected and
control flow analysis requires a dummy return statement after the assert (which is mostly clutter).
Therefore, in the above case, I'd certainly go with an explicit (and more concise)
throw new AssertionError("invalid type " + type);
instead of an assert followed by a dummy return.
As mentioned in the comments, this is assuming that type is an internal parameter and an invalid value indicates a bug in the logic itself. If it is an input parameter, it should be validated according to the usual rules and an IllegalArgumentException be thrown if validation fails.
Following the Oracle guidelines (Programming with assertions), assertions was designed for testing purposes:
An assertion is a statement in the Java programming language that
enables you to test your assumptions about your program. For example,
if you write a method that calculates the speed of a particle, you
might assert that the calculated speed is less than the speed of
light.
Each assertion contains a boolean expression that you believe will be
true when the assertion executes. If it is not true, the system will
throw an error. By verifying that the boolean expression is indeed
true, the assertion confirms your assumptions about the behavior of
your program, increasing your confidence that the program is free of
errors.
In your example, the developer assumed that the code never reaches the assert statement. If, by rare occurrence it does, the assert(false) will throw an Error (since it should never get there). This was done for testing purposes. So, use assert purely for testing purposes.
I’m from a .NET background and now dabbling in Java.
Currently, I’m having big problems designing an API defensively against faulty input. Let’s say I’ve got the following code (close enough):
public void setTokens(Node node, int newTokens) {
tokens.put(node, newTokens);
}
However, this code can fail for two reasons:
User passes a null node.
User passes an invalid node, i.e. one not contained in the graph.
In .NET, I would throw an ArgumentNullException (rather than a NullReferenceException!) or an ArgumentException respectively, passing the name of the offending argument (node) as a string argument.
Java doesn’t seem to have equivalent exceptions. I realize that I could be more specific and just throw whatever exception comes closest to describing the situation, or even writing my own exception class for the specific situation.
Is this the best practice? Or are there general-purpose classes similar to ArgumentException in .NET?
Does it even make sense to check against null in this case? The code will fail anyway and the exception’s stack trace will contain the above method call. Checking against null seems redundant and excessive. Granted, the stack trace will be slightly cleaner (since its target is the above method, rather than an internal check in the HashMap implementation of the JRE). But this must be offset against the cost of an additional if statement, which, furthermore, should never occur anyway – after all, passing null to the above method isn’t an expected situation, it’s a rather stupid bug. Expecting it is downright paranoid – and it will fail with the same exception even if I don’t check for it.
[As has been pointed out in the comments, HashMap.put actually allows null values for the key. So a check against null wouldn’t necessarily be redundant here.]
The standard Java exception is IllegalArgumentException. Some will throw NullPointerException if the argument is null, but for me NPE has that "someone screwed up" connotation, and you don't want clients of your API to think you don't know what you're doing.
For public APIs, check the arguments and fail early and cleanly. The time/cost barely matters.
Different groups have different standards.
Firstly, I assume you know the difference between RuntimeExceptions (unchecked) and normal Exceptions (checked), if not then see this question and the answers. If you write your own exception you can force it to be caught, whereas both NullPointerException and IllegalArgumentException are RuntimeExceptions which are frowned on in some circles.
Secondly, as with you, groups I've worked with but don't actively use asserts, but if your team (or consumer of the API) has decided it will use asserts, then assert sounds like precisely the correct mechanism.
If I was you I would use NullPointerException. The reason for this is precedent. Take an example Java API from Sun, for example java.util.TreeSet. This uses NPEs for precisely this sort of situation, and while it does look like your code just used a null, it is entirely appropriate.
As others have said IllegalArgumentException is an option, but I think NullPointerException is more communicative.
If this API is designed to be used by outside companies/teams I would stick with NullPointerException, but make sure it is declared in the javadoc. If it is for internal use then you might decide that adding your own Exception heirarchy is worthwhile, but personally I find that APIs which add huge exception heirarchies, which are only going to be printStackTrace()d or logged are just a waste of effort.
At the end of the day the main thing is that your code communicates clearly. A local exception heirarchy is like local jargon - it adds information for insiders but can baffle outsiders.
As regards checking against null I would argue it does make sense. Firstly, it allows you to add a message about what was null (ie node or tokens) when you construct the exception which would be helpful. Secondly, in future you might use a Map implementation which allows null, and then you would lose the error check. The cost is almost nothing, so unless a profiler says it is an inner loop problem I wouldn't worry about it.
In Java you would normally throw an IllegalArgumentException
If you want a guide about how to write good Java code, I can highly recommend the book Effective Java by Joshua Bloch.
It sounds like this might be an appropriate use for an assert:
public void setTokens(Node node, int newTokens) {
assert node != null;
tokens.put(node, newTokens);
}
Your approach depends entirely on what contract your function offers to callers - is it a precondition that node is not null?
If it is then you should throw an exception if node is null, since it is a contract violation. If it isnt then your function should silently handle the null Node and respond appropriately.
I think a lot depends on the contract of the method and how well the caller is known.
At some point in the process the caller could take action to validate the node before calling your method. If you know the caller and know that these nodes are always validated then i think it is ok to assume you'll get good data. Essentially responsibility is on the caller.
However if you are, for example, providing a third party library that is distributed then you need to validate the node for nulls, etcs...
An illegalArugementException is the java standard but is also a RunTimeException. So if you want to force the caller to handle the exception then you need to provided a check exception, probably a custom one you create.
Personally I'd like NullPointerExceptions to ONLY happen by accident, so something else must be used to indicate that an illegal argument value was passed. IllegalArgumentException is fine for this.
if (arg1 == null) {
throw new IllegalArgumentException("arg1 == null");
}
This should be sufficient to both those reading the code, but also the poor soul who gets a support call at 3 in the morning.
(and, ALWAYS provide an explanatory text for your exceptions, you will appreciate them some sad day)
like the other : java.lang.IllegalArgumentException.
About checking null Node, what about checking bad input at the Node creation ?
I don't have to please anybody, so what I do now as canonical code is
void method(String s)
if((s != null) && (s instanceof String) && (s.length() > 0x0000))
{
which gets me a lot of sleep.
Others will disagree.
Are there any hard and fast rules regarding returning boolean in a method signature to indicate a successful operation as opposed to declaring void? I find that for more critical operations in my calling method I want to know if an operation completed so I can log any issues. Is this an "inappropriate" use of boolean?
Usually I use Exceptions to signal when something went wrong.
Instead of returning false, you can throw an Exception with a detailed message about what the problem was.
Returning false doesn't give you much information about the problem.
Then, instead of checking for a false return value, just put the method call in try/catch if you expect that the method could easily fail.
Many people will complain that this method is slower. But, the benefits you gain greatly outweigh the slowdown. Besides, if you are using Java speed shouldn't be your #1 concern.
I generally find that throwing an exception in the case of a failure is a far better solution than returning a boolean, because generally do not care if the process has succeeded - I only care if it's failed. By using an exception I can provide any amount of information about why the process actually failed.
If exceptions seem distasteful, you can return a custom Status object which contains a boolean and a status message (something like "Added 6 new Foobars!" or "Could not add Foobars because the Foobin is full!"), although that is of course more complex.
Only do this in scenarios where it's clear that something has a boolean outcome. Like IsValidCustomer() or some such.
For all other things where you think you could introduce it, it probably means you're dealing with some kind of Exception, and you really don't want to wrap that with a simple boolean true/false, because you can have a variety of flavours (different exceptions) and reasons why something goes wrong, which you would want to know about.
So either let the exception bubble up the stack, or catch it and turn it into a custom exception or log it or whatever.
Use boolean values to indicate non-exceptional failure outcomes. An example would be a search function. The nominal failure would be not-found. Communicating that outcome with exceptions is unwieldy. Save exceptions for exceptional cases; the difference between not-found and cannot-search.
This is an ok paradigm, but if you want to force the caller to handle the case wehre the operation doesn't complete successfully, you might want to throw a checked exception instead.
This pattern does occur in the core Java libraries, though. See File.delete() as an example.
For returning success generally what you see is:
Return a boolean
Return void, but throw exception on error
Return a status code (less common in java).
Can't see anything wrong with returning a boolean for success, unless you'd need information on exception behavior.
If there is an unexpected result, throw an exception.
If you just want the function to tell you "did I do X" then return a boolean.
In practice, I find that throwing an Exception is the best thing to do when failure means that we need to abort the process. Like, if you're trying to process an order -- bill the customer, arrange shipping, pay sales taxes, etc -- if you can't find the order record, there's probably little point in doing all the other work. You just want to get out of there. Exceptions let you do this easily. Just catch at the bottom of the block, display or log the error, and get out.
On the other hand, if an "error" means that my program takes a different flow path, returning a boolean makes more sense. Like, if I'm looking for a specific customer and if he exists I update his record and if he doesn't I create a new customer record, then it makes a lot of sense to return a boolean, and in the caller test it and when true follow one path and when false the other.
Really this is two very different meanings of the word "error", and they call for different handling. It is quite possible that the same function could do both. Like, on found return true, on not found return false, on I/O error trying to read throw an exception.
It seem ok, but the devil lies into the details. ;-)
Throwing an exception is the main alternative, with pros and cons.
I think you could get more insight by providing precise coding samples...
I currently have a technical point of difference with an acquaintance. In a nutshell, it's the difference between these two basic styles of Java exception handling:
Option 1 (mine):
try {
...
} catch (OneKindOfException) {
...
} catch (AnotherKind) {
...
} catch (AThirdKind) {
...
}
Option 2 (his):
try {
...
} catch (AppException e) {
switch(e.getCode()) {
case Constants.ONE_KIND:
...
break;
case Constants.ANOTHER_KIND:
...
break;
case Constants.A_THIRD_KIND:
...
break;
default:
...
}
}
His argument -- after I used copious links about user input validation, exception handling, assertions and contracts, etc. to back up my point of view -- boiled down to this:
"It’s a good model. I've used it since me and a friend of mine came up with it in 1998, almost 10 years ago. Take another look and you'll see that the compromises we made to the academic arguments make a lot of sense."
Does anyone have a knock-down argument for why Option 1 is the way to go?
When you have a switch statement, you're less object oriented. There are also more opportunities for mistakes, forgetting a "break;" statement, forgetting to add a case for an Exception if you add a new Exception that is thrown.
I also find your way of doing it to be MUCH more readable, and it's the standard idiom that all developers will immediately understand.
For my taste, the amount of boiler plate to do your acquaintance's method, the amount of code that has nothing to do with actually handling the Exceptions, is unacceptable. The more boilerplate code there is around your actual program logic, the harder the code is to read and to maintain. And using an uncommon idiom makes code more difficult to understand.
But the deal breaker, as I said above, is that when you modify the called method so that it throws an additional Exception, you will automatically know you have to modify your code because it will fail to compile. However, if you use your acquaintance's method and you modify the called method to throw a new variety of AppException, your code will not know there is anything different about this new variety and your code may silently fail by going down an inappropriate error-handling leg. This is assuming that you actually remembered to put in a default so at least it's handled and not silently ignored.
the way option 2 is coded, any unexpected exception type will be swallowed! (this can be fixed by re-throwing in the default case, but that is arguably an ugly thing to do - much better/more efficient to not catch it in the first place)
option 2 is a manual recreation of what option 1 most likely does under the hood, i.e. it ignores the preferred syntax of the language to use older constructs best avoided for maintenance and readability reasons. In other words, option 2 is reinventing the wheel using uglier syntax than that provided by the language constructs.
clearly, both ways work; option 2 is merely obsoleted by the more modern syntax supported by option 1
I don't know if I have a knock down argument but initial thoughts are
Option 2 works until your trying to catch an Exception that doesn't implement getCode()
Option 2 encourages the developer to catch general exceptions, this is a problem because if you don't implement a case statement for a given subclass of AppException the compiler will not warn you. Ofcourse you could run into the same problem with option 1 but atleast option 1 does not activly encourage this.
With option 1, the caller has the option of selecting exactly which exception to catch, and to ignore all others. With option 2, the caller has to remember to re-throw any exceptions not explicitly caught.
Additionally, there's better self-documentation with option 1, as the method signature needs to specify exactly which exceptions are thrown, rather than a single over-riding exception.
If there's a need to have an all-encompassing AppException, the other exception types can always inherit from it.
The knock-down argument would be that it breaks encapsulation since I now I have to know something about the subclass of Exception's public interface in order to handle exceptions by it. A good example of this "mistake" in the JDK is java.sql.SQLException, exposing getErrorCode and getSQLState methods.
It looks to me like you're overusing exceptions in either case. As a general rule, I try to throw exceptions only when both of the following are true:
An unexpected condition has occurred that cannot be handled here.
Somebody will care about the stack trace.
How about a third way? You could use an enum for the type of error and simply return it as part of the method's type. For this, you would use, for example, Option<A> or Either<A, B>.
For example, you would have:
enum Error { ONE_ERROR, ANOTHER_ERROR, THIRD_ERROR };
and instead of
public Foo mightError(Bar b) throws OneException
you will have
public Either<Error, Foo> mightError(Bar b)
Throw/catch is a bit like goto/comefrom. Easy to abuse. See Go To Statement Considered Harmful. and Lazy Error Handling
I think it depends on the extent to which this is used. I certainly wouldn't have "one exception to rule them all" which is thrown by everything. On the other hand, if there is a whole class of situations which are almost certainly going to be handled the same way, but you may need to distinguish between them for (say) user feedback purposes, option 2 would make sense just for those exceptions. They should be very narrow in scope - so that wherever it makes sense for one "code" to be thrown, it should probably make sense for all the others to be thrown too.
The crucial test for me would be: "would it ever make sense to catch an AppException with one code, but want to let another code remain uncaught?" If so, they should be different types.
Each checked Exception is an, um, exception condition that must be handled for the program behavior to be defined. There's no need to go into contractual obligations and whatnot, it's a simple matter of meaningfulness. Say you ask a shopkeeper how much something costs and it turns out the item is not for sale. Now, if you insist you'll only accept non-negative numerical values for an answer, there is no correct answer that could ever be provided to you. This is the point with checked exceptions, you ask that some action be performed (perhaps producing a response), and if your request cannot be performed in a meaningful manner, you'll have to plan for that reasonably. This is the cost of writing robust code.
With Option 2 you are completely obscuring the meaning of the exception conditions in your code. You should not collapse different error conditions into a single generic AppException unless they will never need to be handled differently. The fact that you're branching on getCode() indicates otherwise, so use different Exceptions for different exceptions.
The only real merit I can see with Option 2 is for cleanly handling different exceptions with the same code block. This nice blog post talks about this problem with Java. Still, this is a style vs. correctness issue, and correctness wins.
I'd support option 2 if it was:
default:
throw e;
It's a bit uglier syntax, but the ability to execute the same code for multiple exceptions (ie cases in a row) is much better. The only thing that would bug me is producing a unique id when making an exception, and the system could definitely be improved.
Unnecessary have to know the code and declare constants for the exception which could have been abstract when using option 1.
The second option (as I guess) will change to traditional (as option 1) when there is only one specific exception to catch, so I see inconsistencey over there.
Use both.
The first for most of the exceptions in your code.
The second for those very "specific" exceptions you've create.
Don't struggle with little things like this.
BTW 1st is better.