Let say you have a method that checks if the argument (Answer) is correct and check if the question already have answers in the list that is also correct:
public void addAnswer(Answer answer) {
if (answer.isCorrect()) {
...
}
}
However, I only want one answer to be correct in the list. I have multiple options. I could throw an exception, I could ignore it, I could return some boolean value from the addAnswer that tells me if the operation was ok or not. How are you supposed to think in such scenarios?
The rule is pretty simple: Use exceptions on exceptional, erroneous, unpredicted failures. Don't use exceptions when you expect something to happen or when something happens really often.
In your case it's not an error or something truly rare that an answer is not correct. It's part of your business logic. You can throw an exception, but only as part of some validation (assertion) if you expect an answer at given point to always be correct and suddenly it's not (precondition failure).
And of course if some failure occurs while checking correctness (database connection lost, wrong array index) exception are desired.
This entirely depends on what you want to achieve. Should the caller of your method already have made sure that it doesn't add two correct answers? Is it a sign of a programming error if that happens? Then throw an exception, but definitely an unchecked exception.
If your method's purpose is to relieve the caller from enforcing the one-true-answer invariant (I doubt that, though), then you can just arrange to signal via a boolean return value, which makes it only an optional information channel for the caller.
If there is no way to know in advance whether there are other correct answers—for example, the answers are added concurrently from several threads or even processes (via a database)—then it would be meaningful to throw a checked exception.
Bottom line: there is no one-size-fits-all best practice, but there is a best practice for every scenario you want to accomplish.
The exception police will be down on you like a ton of bricks, and me for this answer, with statements like "don't use exceptions for flow control" and "don't use exceptions for normal conditions".
The trouble with the first statement is that exceptions are a form of flow control. This makes the argument self-contradictory, and therefore invalid.
The trouble with the second statement is that it seems to inevitably go along with endlessly redefining exceptional conditions as normal. You will find examples in this very site: for example, a lively discussion where the police insisted that EOF was 'normal' and therefore that EOFException shouldn't be caught, despite the existence of dozens of Java APIs that don't give you any choice in the matter. Travel far enough down this path and you can end up with nothing that is exceptional whatsoever, and therefore no occasion to use them at all.
These are not logical arguments. These are unexamined dogmas.
The original and real point, back in about 1989 when it was first formulated, was that you shouldn't throw exceptions to yourself, to be handled in the same method: in other words, don't treat it as a GOTO. This principle continues to have validity.
The point about checked exceptions is that you force the caller to do something about handling them. If you believe, on your own analysis, that this is what you want, use an exception. Or, if you are using an API that forces you to catch them, catch them, at the appropriate level (whatever that is: left as an exercise for the reader).
In other words, like most things in the real world, it is up to your discretion and judgment. The feature is there to be used, or abused, like anything else.
#Exception police: you will find me in the telephone book. But be prepared for an argument.
An exception thrown from a method enforces the callers to take some action in the anticipation of the exception occurring for some inputs. A return value doesn't enforce the same and so it is up to the caller to capture it and take some action.
If you want the callers to handle the scenario to take some corrective action, then you should throw a checked exception (sub class of java.lang.Exception).
The problem here is that your API is error prone. I'd use the following scheme instead:
public class Question {
private List<Answer> answers;
private int mCorrect;
// you may want a List implementation without duplicates
public void setAnswers(List<Answer> answers, int correct) {
this.answers = answers;
// check if int is between bounds
mCorrect = correct;
}
public boolean isCorrect(Answer answer) {
return answers.indexOf(answer) == mCorrect;
}
}
because an Answer by itself is simply a statement, and usually cannot be true of false without being associated to a Question. This API makes it impossible to have zero or more than one correct answers, and forces the user to supply the correct one when he adds answers, so your program is always in a consistent state and simply can't fail.
Before deciding how to signal errors, it's always better to design the API so that errors are less common as possible. With your current implementation, you have to make checks on your side, and the client programmer must check on his side as well. With the suggested design no check is needed, and you'll have correct, concise and fluent code on both sides.
Regarding when to use a boolean and when to use Exceptions, I often see boolean used to mirror the underlying API (mostly low level C-code).
I agree with Tomasz Nurkiewicz's response. I cant comment on it because I'm a new user. I would also recommend that if the addAnswer() method is not always going to add the answer (because they already exists a correct one), name it to suggest this behaviour. "add" is suggest normal collections behaviour.
public boolean submitAnswer(Answer answer); // returns true is answer accepted
Your exact solution may depend on the bigger picture about your application that we dont know about. Maybe you do want to throw an Exception but also make it the responsibility of the caller to check if adding the Answer is valid.
It's all a rich tapestry.
I would implement it in this way:
public class Question {
private int questionId;
private final Set<Answer> options = new HashSet<Answer>();
private final Set<Answer> correctAnswers = new HashSet<Answer>();
public boolean addAnswer(Answer answer) throws WrongAnswerForThisQuestionException {
if(!answer.isValid(questionId)) {
throw new WrongAnswerForThisQuestionException(answer, this);
}
if (answer.isCorrect(questionId)) {
correctAnswers.add(answer);
}
return options.add(answer);
}
}
Related
Given the code:
public static int sum(String a, String b) /* throws? WHAT? */ {
int x = Integer.parseInt(a); // throws NumberFormatException
int y = Integer.parseInt(b); // throws NumberFormatException
return x + y;
}
Could you tell if it's good Java or not? What I'm talking about is, NumberFormatException is an unchecked exception. You don't have to specify it as part of sum() signature. Moreover, as far as I understand, the idea of unchecked exceptions is just to signal that program's implementation is incorrect, and even more, catching unchecked exceptions is a bad idea, since it's like fixing bad program at runtime.
Would somebody please clarify whether:
I should specify NumberFormatException as a part of method's signature.
I should define my own checked exception (BadDataException), handle NumberFormatException inside the method and re-throw it as BadDataException.
I should define my own checked exception (BadDataException), validate both strings some way like regular expressions and throw my BadDataException if it doesn't match.
Your idea?
Update:
Imagine, it's not an open-source framework, that you should use for some reason. You look at method's signature and think - "OK, it never throws". Then, some day, you got an exception. Is it normal?
Update 2:
There are some comments saying my sum(String, String) is a bad design. I do absolutely agree, but for those who believe that original problem would just never appear if we had good design, here's an extra question:
The problem definition is like this: you have a data source where numbers are stored as Strings. This source may be XML file, web page, desktop window with 2 edit boxes, whatever.
Your goal is to implement the logic that takes these 2 Strings, converts them to ints and displays message box saying "the sum is xxx".
No matter what's the approach you use to design/implement this, you'll have these 2 points of inner functionality:
A place where you convert String to int
A place where you add 2 ints
The primary question of my original post is:
Integer.parseInt() expects correct string to be passed. Whenever you pass a bad string, it means that your program is incorrect (not "your user is an idiot"). You need to implement the piece of code where on one hand you have Integer.parseInt() with MUST semantics and on the other hand you need to be OK with the cases when input is incorrect - SHOULD semantics.
So, briefly: how do I implement SHOULD semantics if I only have MUST libraries.
In my opinion it would be preferable to handle exception logic as far up as possible. Hence I would prefer the signature
public static int sum(int a, int b);
With your method signature I would not change anything. Either you are
Programmatically using incorrect values, where you instead could validate your producer algorithm
or sending values from e.g., user input, in which case that module should perform the validation
Hence, exception handling in this case becomes a documentation issue.
This is a good question. I wish more people would think about such things.
IMHO, throwing unchecked exceptions is acceptable if you've been passed rubbish parameters.
Generally speaking, you shouldn't throw BadDataException because you shouldn't use Exceptions to control program flow. Exceptions are for the exceptional. Callers to your method can know before they call it if their strings are numbers or not, so passing rubbish in is avoidable and therefore can be considered a programming error, which means it's OK to throw unchecked exceptions.
Regarding declaring throws NumberFormatException - this is not that useful, because few will notice due to NumberFormatException being unchecked. However, IDE's can make use of it and offer to wrap in try/catch correctly. A good option is to use javadoc as well, eg:
/**
* Adds two string numbers
* #param a
* #param b
* #return
* #throws NumberFormatException if either of a or b is not an integer
*/
public static int sum(String a, String b) throws NumberFormatException {
int x = Integer.parseInt(a);
int y = Integer.parseInt(b);
return x + y;
}
EDITED:
The commenters have made valid points. You need to consider how this will be used and the overall design of your app.
If the method will be used all over the place, and it's important that all callers handle problems, the declare the method as throwing a checked exception (forcing callers to deal with problems), but cluttering the code with try/catch blocks.
If on the other hand we are using this method with data we trust, then declare it as above, because it is not expected to ever explode and you avoid the code clutter of essentially unnecessary try/catch blocks.
Number 4. As given, this method should not take strings as parameters it should take integers. In which case (since java wraps instead of overflowing) there's no possibility of an exception.
x = sum(Integer.parseInt(a), Integer.parseInt(b))
is a lot clearer as to what is meant than
x = sum(a, b)
You want the exception to happen as close to the source (input) as possible.
As to options 1-3, you don't define an exception because you expect your callers to assume that otherwise your code can't fail, you define an exception to define what happens under known failure conditions WHICH ARE UNIQUE TO YOUR METHOD. I.e. if you have a method that is a wrapper around another object, and it throws an exception then pass it along. Only if the exception is unique to your method should you throw a custom exception (frex, in your example, if sum was supposed to only return positive results, then checking for that and throwing an exception would be appropriate, if on the other hand java threw an overflow exception instead of wrapping, then you would pass that along, not define it in your signature, rename it, or eat it).
Update in response to update of the question:
So, briefly: how do I implement SHOULD semantics if I only have MUST libraries.
The solution to this is to to wrap the MUST library, and return a SHOULD value. In this case, a function that returns an Integer. Write a function that takes a string and returns an Integer object -- either it works, or it returns null (like guava's Ints.tryParse). Do your validation seperate from your operation, your operation should take ints. Whether your operation gets called with default values when you have invalid input, or you do something else, will depend upon your specs -- most I can say about that, is that it's really unlikely that the place to make that decision is in the operation method.
1. I should specify NumberFormatException as a part of method's signature.
I think so. It's a nice documentation.
2. I should define my own checked exception (BadDataException), handle NumberFormatException inside the method and re-throw it as BadDataException.
Sometimes yes. The checked exceptions are consider to be better in some cases, but working with them is quite a PITA. That's why many frameworks (e.g., Hibernate) use runtime exceptions only.
3. I should define my own checked exception (BadDataException), validate both strings some way like regular expressions and throw my BadDataException if it doesn't match.
Never. More work, less speed (unless you expect throwing the exception to be a rule), and no gain at all.
4. Your idea?
None at all.
Nr 4.
I think I wouldn't change the method at all.
I would put a try catch around the calling method or higher in the stack-trace where I'm in a context where I can gracefully recover with business logic from the exception.
I wouldn't certainty do #3 as I deem it overkill.
Assuming that what you are writing is going to be consumed (like as an API) by someone else, then you should go with 1, NumberFormatException is specifically for the purpose of communicating such exceptions and should be used.
First you need to ask your self, does the user of my method needs to worry about entering wrong data, or is it expected of him to enter proper data (in this case String).
This expectation is also know as design by contract.
and 3. Yes you probably should define BadDataException or even better use some of the excising ones like NumberFormatException but rather the leaving the standard message to be show. Catch NumberFormatException in the method and re-throw it with your message, not forgetting to include the original stack trace.
It depends on the situation bu I would probably go with re-throwing NumberFormatException with some additional info. And also there must be a javadoc explanation of what are the expected values for String a, String b
Depends a lot on the scenario you are in.
Case 1. Its always you who debug the code and no one else and exception wont cause a bad user experience
Throw the default NumberFormatException
Case2: Code should be extremely maintainable and understandable
Define your own exception and add lot more data for debugging while throwing it.
You dont need regex checks as, its gonna go to exception on bad input anyway.
If it was a production level code, my idea would be to define more than one custom exceptions, like
Number format exception
Overflow exception
Null exception etc...
and deal with all these seperately
You may do so, to make it clear that this can happen for incorrect input. It might help someone using your code to remember handling this situation. More specifically, you're making it clear that you don't handle it in the code yourself, or return some specific value instead. Of course, the JavaDoc should make this clear too.
Only if you want to force the caller to deal with a checked exception.
That seems like overkill. Rely on the parsing to detect bad input.
Overal, a NumberFormaException is unchecked because it is expected that correctly parseable input is provided. Input validation is something you should handle. However, actually parsing the input is the easiest way to do this. You could simply leave your method as it is and warn in the documentation that correct input is expected and anyone calling your function should validate both inputs before using it.
Any exceptional behaviour should be clarified in the documentation. Either it should state that this method returns a special value in case the of failure (like null, by changing the return type to Integer) or case 1 should be used. Having it explicit in the method's signature lets the user ignore it if he ensures correct strings by other means, but it still is obvious that the method doesn't handle this kind of failure by itself.
Answer to your updated question.
Yes it's perfectly normal to get "surprise" exceptions.
Think about all the run time errors one got when new to programming.
e.g ArrayIndexOutofBound
Also a common surprise exception from the for each loop.
ConcurrentModificationException or something like that
While I agree with the answer that the runtime exception should be allowed to be percolated, from a design and usability perspective, it would be a good idea to wrap it into a IllegalArgumentException rather than throw it as NumberFormatException. This then makes the contract of your method more clear whereby it declares an illegal argument was passed to it due to which it threw an exception.
Regarding the update to the question "Imagine, it's not an open-source framework, that you should use for some reason. You look at method's signature and think - "OK, it never throws". Then, some day, you got an exception. Is it normal?" the javadoc of your method should always spill out the behavior of your method (pre and post constraints). Think on the lines of say collection interfaces where in if a null is not allowed the javadoc says that a null pointer exception will be thrown although it is never part of the method signature.
As you are talking about good java practice ,in my opinion it is always better
To handle the unchecked exception then analyze it and through a custom unchecked exception.
Also while throwing custom unchecked exception you can add the Exception message that your client could understand and also print the stack trace of original exception
No need to declare custom exception as "throws" as it is unchecked one.
This way you are not violating the use of what unchecked exceptions are made for, at the same time client of the code would easily understand the reason and solution for the exception .
Also documenting properly in java-doc is a good practice and helps a lot.
I think it depends on your purpose, but I would document it at a minimum:
/**
* #return the sum (as an int) of the two strings
* #throws NumberFormatException if either string can't be converted to an Integer
*/
public static int sum(String a, String b)
int x = Integer.parseInt(a);
int y = Integer.parseInt(b);
return x + y;
}
Or, take a page from the Java source code for the java.lang.Integer class:
public static int parseInt(java.lang.String string) throws java.lang.NumberFormatException;
How about the input validation pattern implemented by Google's 'Guava' library or Apache's 'Validator' library (comparison)?
In my experience, it is considered good practice to validate a function's parameters at the beginning of the function and throw Exceptions where appropriate.
Also, I would consider this question to be largely language independent. The 'good practice' here would apply to all languages that have functions which can take parameters which may or may not be valid.
I think your very first sentence of "Quite a stupid question" is very relevant. Why would you ever write a method with that signature in the first place? Does it even make sense to sum two strings? If the calling method wants to sum two strings, it is the calling method's responsibility to make sure they are valid ints and to convert them before calling the method.
In this example, if the calling method cannot convert the two Strings into an int, it could do several things. It really depends at what layer this summation occurs at. I am assuming the String conversion would be very close to front-end code (if it was done properly), such that case 1. would be the most likely:
Set an error message and stop processing or redirect to an error page
Return false (ie, it would put the sum into some other object and would not be required to return it)
Throw some BadDataException as you are suggesting, but unless the summation of these two numbers is very important, this is overkill, and like mentioned above, this is probably bad design since it implies that the conversion is being done in the wrong place
There are lots of interesting answers to this question. But I still want to add this :
For string parsing, I always prefer to use "regular expressions". The java.util.regex package is there to help us. So I will end up with something like this, that never throws any exception. It's up to me to return a special value if I want to catch some error :
import java.util.regex.Pattern;
import java.util.regex.Matcher;
public static int sum(String a, String b) {
final String REGEX = "\\d"; // a single digit
Pattern pattern = Pattern.compile(REGEX);
Matcher matcher = pattern.matcher(a);
if (matcher.find()) { x = Integer.matcher.group(); }
Matcher matcher = pattern.matcher(b);
if (matcher.find()) { y = Integer.matcher.group(); }
return x + y;
}
As one can see, the code is just a bit longer, but we can handle what we want (and set default values for x and y, control what happens with else clauses, etc...)
We could even write a more general transformation routine, to which we can pass strings, defaut return values, REGEX code to compile, error messages to throw, ...
Hope It was usefull.
Warning : I was not able to test this code, so please excuse eventual syntax problems.
You face this issue because you let user errors propagate too deep into the core of the application and partly also because you abuse Java data types.
You should have a clearer separation between user input validation and business logic, use proper data typing, and this problem will disappear by itself.
The fact is the semantics of Integer.parseInt() are known - it's primary purpose it to parse valid integers. You're missing an explicit user input validation/parsing step.
I have this method, that can return three different response.
At first, it was supposed just only return two, so I make its return type to Boolean
like:
public static boolean isLoteWaitingForImage()
And some business logic came out with that it can has another result, so the method was modified to
public static boolean isLoteWaitingForImage() throws ImageNotPendingException
If a certain select return a null value, but one row its return true, if its not null i will return false. If no row was acquired from the select I will throw an ImageNotPendingException cause it doesn't apply for the given filters in the where clause.
Also thought about doing it in this Way, I have this new Class with the types that are valid to return from the method isLoteWaitingForImage(), with 3 constants properties called:
public class LoteResponse {
public static int VALID = 1;
public static int INVALID = 2;
public static int NO_IMAGE_PENDING = 3;
}
So I will have this new method:
public static int isLoteWaitingForImage() {
return LoteResponse.VALID;
}
Having this on table, I have these two questions:
Any "other" idea about how to accomplish this needing?
Which method is a better practice?
Yes, that looks like an abuse to me.
It would be reasonable to throw the exception if the method simply shouldn't be called when no image is pending. Can the client always know that? Does it represent a bug, or something else going badly wrong for them to be calling it in that state? If not, don't use an exception.
It looks to me like you need an enum.
public enum LoteResponseState
{
Valid,
Invalid,
NoImagePending;
}
public static LoteResponseState getLoteState()
{
...
}
If you expect the code that calls isLoteWaitingForImage() to be directly responsible for handling the "no image pending" condition as well as the others, then use the multiple return values, but use an enum, not ints!
If the "no image pending" condition cannot be usefully handled by the immediate calling code and instead would usually be handled higher up the call stack, then the exception is the better option.
I definitely agree that an enum is the best choice.
As a general rule, if a certain operation is not considered a serious error that will rarely occur, you should not throw an exception. Throw exceptions only for errors that the current method cannot have any way of handling in a useful way, but not as a typical return value.
I am no expert so don't take this as a best-practice advice, but I think using exceptions in this particular case seems like an overkill. I would go for some simple return values as mentioned above.
If you really want to keep track of the situation, for whatever debugging or developing reason, you could perhaps throw RuntimeException("why a runtime exception is thrown") instead. Writing an own Exception seems too excessive if you are not doing something particular with the exception.
I hope that makes some sense. :)
Go for the exception way. It does have a more explicit interface to the caller. If the caller needs to process this ImageNotPendingException make it an Checked Exception.
Returning enum is a bizarre thing as it diminishes encapsulation by delegating business detail and processing to the caller. This way the caller needs to know way too much of the calee.
Sorry about my bad english.
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.