Using exceptions for user error

Question

I'm working on an IRC bot that should handle some user commands, lets take !login <username> <password> for example. Sometimes the user forgets to enter their password, so instead of sending !login myUser hunter2 they might use !login myUser . In this case, the user should be replied to with an error message. The method that actually handles the command handleCommand is always wrapped by another method wrapperMethod . Which of the following ways should I use to handle user errors: should handleCommand just message the user about what happened and exit itself, or should it throw an exception with the error message and let wrapperMethod do the rest? ( String[] command is the original command without the ! and split by spaces, so !login myUser hunter2 would become {"login", "myUser", "hunter2"} )

Using exceptions:

public void wrapperMethod(Object sender, Object receiver, String[] command) {
    try {
        handleCommand(sender, receiver, command);
    catch(CommandExecutionException e) {
        receiver.sendTo(sender, e.getMessage());
    }
}

private void handleCommand(Object sender, Object receiver, String[] command) {
    if(command.length != 3)
        throw new CommandExecutionException("Things went wrong");
    //Do things
}

Not using exceptions:

public void wrapperMethod(Object sender, Object receiver, String[] command) {
    handleCommand(sender, receiver, command);
}
private void handleCommand(Object sender, Object receiver, String[] command)
    if(command.length != 3) {
        receiver.sendTo(sender, "Things went wrong");
        return;
    }
    //Do things
}

Which type should I prefer and why ? Right now, I'm thinking of going with exceptions simply because I can save a few lines of code that I really don't need. When a user error is detected, handleCommand is always halted immediately. There's also the possiblility of having handleCommand return Optional<Error> or something like that, but this seems really fishy.

Answer 1

Exceptions are expensive . Using them as flow control is strongly discouraged. It also means that your code could complete abruptly, and makes it harder to debug or read.

I'd go a different route: use Hibernate Validators . They're not difficult to set up or establish in your code, and using them means that your input is validated before you ever attempt to manipulate things. It also keeps your validation logic and actual business logic separate.

If you don't want to go that route, I'd encourage the latter approach - although, I'd use an else instead of return from a void method.

Answer 2

I prefer option with exceptions, because it separates normal processing from error handling.

In second option method handleCommand is responsible for both.

First option follows Single responsibility principle : method handleCommand handles correct flow, if something goes wrong throw exception and allow someone else cares the problem.

Moreover, assume that within section

//Do things

you find other error. If you use exception, you may keep consistent and clean pattern that any error triggers exception and someone who catch the exception cares correct handling.

Don't worry that exceptions are expensive; planes are more expensive that bikes, but if you go for vacation to Bali, use rather plane than bike (not applicable for Bali citizens:) ). Exceptions are designed for exceptions , as long as you don't use them in regular processing, it is OK.