A RuntimeException is a programming error

No function should ever throw a RuntimeException by design, unless it has documented requirements for its arguments or object state that are not fulfilled. Essentially, it must always be possible for the caller of a function to do enough checking so that it can be sure no RuntimeException will be thrown. Continue reading “A RuntimeException is a programming error” →

Don’t use throws Exception or throws Throwable

Using throws Throwable and throws Exception subverts the exception checking system. If you do this, callers are forced to catch Throwable or Exception, which may catch both unchecked and checked exceptions. This forces callers to use instanceof to see whether the exception is one that they can deal with. Continue reading “Don’t use throws Exception or throws Throwable” →

Junit tests: same package, different directory

Put TestCase classes in the same package as the class they are testing. This makes it easy to test protected and package-visible methods. It’s still a pain to test private methods though.

Put TestCase files in a separate directory to the main source tree. This stops the source tree becoming cluttered with test classes, and also makes it easy to exclude them from your product release builds (since they don’t belong there). Continue reading “Junit tests: same package, different directory” →

Profiling a Java program easily

Profiling is an excellent way to find resource bottlenecks in a program. Java has built-in profiling tools that you can use to easily view a profile of a program’s runtime execution.

To generate a profiling report for a Java program, add the hprof profiler to the program’s command line as follows. Continue reading “Profiling a Java program easily” →

Throw exceptions: don’t return null

If a function that returns an object is unable to return the object because of an error, it should not return null. Instead, it should throw some defined exception. This means that the handling for the error can occur at the appropriate place, by catching the defined exception. This appropriate place may be at the point of the function call, or somewhere further up the call stack. Continue reading “Throw exceptions: don’t return null” →

Java stack trace with line numbers

Often in Java program stack trace, you will see some stack frames include a source line number, while some only say “compiled code”. This is because the stack frames without line numbers have been compiled by the JIT compiler, and the JIT compiler obliterates line number information when it compiles code. Continue reading “Java stack trace with line numbers” →

Spy on a Java program

While a Java program is running in a console window, you can can get a stack dump of the program at any time, while it is running. This is very useful for debugging, especially for heavily multithreaded programs. Continue reading “Spy on a Java program” →

Java versus Daylight savings time

Depending on the version of the Java runtime and the location of the host, the Java Date and Calendar routines may take daylight savings time into account. For example:

  • If you set a Calendar or Date to a specific value and then read it back, you may end up with a time later than the one you set. (You could even conceivably end up with an earlier time if you set it a millisecond before daylight savings time ends, and then read it back after.)
  • Continue reading “Java versus Daylight savings time” →

Don’t tolerate compiler warnings

All code must compile without warnings. All warnings must be fixed before checking code in to a version control system. This applies not only to compiled languages: for example, validation of HTML or CSS code should also be warning-free for the same reasons given here. Continue reading “Don’t tolerate compiler warnings” →

Oracle testing with the DUAL table

This feature is a hack intended for testing, but it’s built in to every Oracle installation.

DUAL is a table automatically created by Oracle and accessible to all users. It has one column, DUMMY, containing one row. It’s useful for selecting a constant or expression, because the table always exists (so the query will succeed) and the result will only be returned once (since there’s exactly one row in the table). Continue reading “Oracle testing with the DUAL table” →