Elegant way to only execute code if it throws no exception

Question

Here is my issue, and I'm surprised to not have found it asked before. Essentially, in faked code, here is my situation:

try
{
    User user = currentUser(); //Throws UnauthenticatedException if not logged in.
    //Do stuff with the user.
}
catch (UnauthenticatedException e)
{
    //Do nothing, it's perfectly fine to not do the above code
    //if the user isn't logged in.
}

I'm not asking about how to handle this specific situation really, I just thought an example would be helpful. My general question is, is there an elegant way to handle cases where an Exception being thrown warrants no further action? That empty catch block hurts my brain to think about, it's so inelegant.

Answer 1

It is pretty simple: situations where you really do want an empty catch block are almost non existent!

Take your example: if login fails... 10 times - don't you think your code should do something about that? So instead of having an empty catch you could

• log the failure so you later understand when and how often that user attempted to log in
• count failures (for example to suspend that user at some point)
• and most obvious - don't you think you should provide a meaningful message to the user

Even if your code is just an example - as you can see it is super easy to come up with arguments against having that empty catch!

Beyond that: when an operation is fine to fail - is it really appropriate to throw an exception then?! Meaning: when that empty catch is possible - why is the code designed to throw at all? What is the point of throwing when catching seems pointless?

Answer 2

Probably, you can add a method to currentUser returning a boolean like this:

currentUser.isLogged()

You can also return null if there is no current user, so testing the user instead of catching exception

Answer 3

You can throw the Exception. However if the user is not logged in the exception will be thrown and the program will end.

public void valid() throws UnauthenticatedException{
    User user = currentUser(); //Throws UnauthenticatedException if not logged in.
}

Normally, Exceptions should be thrown from a method when that method is incapable of resolving the exception on its own.

For the sake of "Elegant Code" this method looks better but may not have the desired out come you want. When it comes down to it, just warm up to try and catching :-)

Answer 4

The empty catch is fine. They are not usually empty, but it is fine for them to be so. It is not uncommon for exceptions to make better control flow than if statements. In fact, that was the reason exceptions were introduced in the first place, to collect your error handling into a better location. Before exceptions, it could get quite messy, especially if you had to jump stack frames.

Take the following example:

public void mainLoop()
{
    while(true)
    {
        try
        {
            Thread.sleep(1000);
            f();
        }
        catch (InterruptedException ex)
        {
            // Don't care; this thread expected to not die when interrupted
        }
    }
}

Sometimes, that really is the best way to handle it.

And as for the "exceptions should not be used for control flow" argument...

Also, sometimes it is convenient to collect all of what you consider your error cases to be into one place, and if they all share the same logic then you can even use a multi-catch.

public void verifyInput()
{
    try
    {
        int n = Integer.parseInt( txtInput.getText() );

        if(n < minimum || n > maximum)
            throw new MyDataInvalidException("data out of bounds");

        sendFormData();
    }
    catch (NumberFormatException | MyDataInvalidException ex)
    {
        // Don't care. Each widget on the form is already set up to display
        //   information about invalid input, so if you press "enter" in
        //   this state just ignore it
    }
}

Now, the above code sample has the added benefit that if, later on, you get a new requirement to handle bad input differently, you can maintain this quickly and easily.

For example, you get complaints that each GUI widget showing its invalid state is not enough, "Please, if I press enter show me a dialog with 'Invalid data: please check all fields.' to let me know I need to scroll up to see the text field's "X blah blah error message"" Now you just replace that comment with a message box popup, perhaps.

Or, if it needs to be handled higher up the stack, change verifyInput to use throws.

Answer 5

Answering my own question here, to explain how I misunderstood, and hopefully if others misunderstand in the same way this will set them straight.

The very reason exceptions get thrown is that if you encounter them, your program has done something that should not have happened. In my case, I was accessing the current user and attempting to basically use the error as the false case of if (user is logged in), which was completely at odds with the design of the method. The method threw an error if no user was logged in because it was specifically designed to never be called if the user wasn't logged in.

The true solution to the issue, at the very least in my case, and, I suspect, in the case of many others who are trying to do what I was doing before I realized the problem, is "Don't do that." Just use the method as it was intended, don't try to hack it.