| This is a list of things that are a good idea to do when writing code in the real world (he writes , as if there is any other world). I don't know if they are the best practices ever. That's pretty hard to determine concretely. -
Do not squash exceptions ”do something useful with them . It is common to see code that catches an exception, and then does nothing. The following will compile:
...catch(Exception e) {}.
Usually it isn't quite that angry , and you see a call to System.out.println() . If your application is a console application, this might be appropriate, but would it be better to save that message to a log file along with a timestamp, class name , and username? You bet. If you are writing a desktop application using the Java Swing API, you could still do that, but in addition, trying passing the exception.get-Message() or exception.getCause() to a JOptionPane.showMessageDialog() . It takes two parameters: the parent component (it can be null ) and the String message to display. This is like a MsgBox in VB or a JavaScript alert. -
Catch exceptions with the narrowest type match practical . That is, design your program keeping in mind that one person's program is another person's API. If it matters to make a distinction between FileNotFoundException and IOException, make that distinction and handle them differently in different catch blocks. More specific is usually better. It's more complete and explicit, and easy to understand. -
Don't proliferate checked exceptions into your API . That means be careful if you find yourself writing loads of methods that throw everything. The reason is this: It makes your API contract more brittle, and you might find your client code becoming overburdened if the client can't do something meaningful with the exception. You don't have checked exceptions in languages like C++ and C#, so programmers coming from those languages may find it a bit of a hassle. -
Don't throw an exception when you can perform a test . They are meant for exceptional situations, and in all likelihood will cause your code to execute more slowly. A lot of times you can perform a test that saves you from the trouble, time, and reduction in readability that adding exception handling code causes. For example, say you have a form allowing a user to log in. If the password is left blank, you don't need to throw an exception. This isn't really exceptional. Users do dumb things all the time, kind of at a breath -taking pace actually; it's like there's a race with a big important prize if you can be the dumbest user. But if you can do if ( password != null) that's way better (simpler, clearer, faster) than throwing an exception about that little oversight. -
Reasonably organize your try blocks with related statements . That means that you shouldn't make a separate try/catch block for each item that throws an exception. Many situations do not call for atomic transactions. Typically, you don't just do one thing in a vacuum , and then do something else totally unrelated to what you just did. You open the file because you want to write to it. You build the URL because you want to connect to it. And then you probably want to read the stream, and do something with that. Sheesh, there's a lot of stuff to do in the world. These things go together. If you didn't build the URL, you don't have much chance of opening that connection, do you? It is okay (good) to put these statements together in one try block, and then deal with whatever problem arises in a catch or two. The lesson: do not write one try block per one potentially -checked-exception-throwing-method if it makes sense to group them together. -
Keep your code encapsulated . As mentioned earlier, you will hopefully design your applications in tiers, your user interface tier separated from your business logic tier, separated from your persistence tier, and so forth. Do not allow exceptions that are specific to the implementation in one tier bubble up to another. That is, do not allow a SQLException up in your client. Because then your client has to deal with it, and it means that it has been thrown up through each of the proceeding tiers. If you change your persistence layer to an XML file or some financial system or something other than a SQL-compliant database, you won't be throwing SQLException anymore, and yet you will have broken the encapsulation that is the very purpose of layering your code in tiers in the first place. To make matters worse , the API is outdated and clogged up with unnecessary code. The solution is easy: Wrap exceptions in code that makes sense for the tier on which it will actually get handled. Do not let this confuse you, though. It is just fine to propagate exceptions, because often a higher layer is the one you want to present the problem to the user. Just do it smart. And so ends our business with exceptions. I hope that you have enjoyed it as much as I have. See you next time. |
