Newsletter sign-up
View all newsletters

Enterprise Java Newsletter
Stay up to date on the latest tutorials and Java community news posted on JavaWorld

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

JavaWorld.com > Java Development Tools >

Java Tip 91: Use nested exceptions in a multitiered environment

Automatically capture the context of remotely thrown exceptions through nesting

By Terren Suydam, JavaWorld.com, 03/31/00

  • Print
  • Feedback
.
In this brave new world of business computing, multitiered applications based on RMI, or Remote Method Invocation, running across many computers have overrun the realm of the business application, also commonly known as the enterprise application. Logically separate tiers, such as a GUI tier and a database tier, divide responsibility and isolate the tasks of an enterprise application into well-defined areas that you can develop independently. A popular breakdown today is a three-tiered model: a client tier, which is solely responsible for presentation and user handling of business data; the middle tier, which implements the business logic; and the database tier, which stores and retrieves data. Unfortunately, multitiered applications introduce new debugging challenges over simpler, single-tiered designs.

Handling exceptions generated on remote tiers is one of the challenges enterprise programmers face. An exception bubbling up through the murky depths of multitier code can't convey the context in which it was thrown, except through its own exception type and error message. Those who haven't experienced the thrills of remote developing might ask, "What about the stack trace?" (The stack trace refers to the list of methods the executing thread has traversed to the current moment -- extremely valuable debugging information that every Java exception stores.) Unfortunately, the RMI framework throws it away when the exception crosses the RMI boundary.

Why is it thrown away? The stack trace is considered a transient property of an exception. When objects are sent across RMI, they are serialized -- converted into a stream of bytes that you can easily transmit over a network wire. This means that any object to be transmitted over RMI, including exceptions, must be serializable (by implementing the java.io.Serializable interface). Java programmers use the keyword transient to describe any field of a class that is considered temporary, such as a temporary file handle. Unfortunately for you, transient fields like the exception's stack trace are not serialized, and thus not reproduced on the new tier.

This makes it difficult to tell when and where a remote exception was thrown, especially when it's a runtime exception like NullPointerException. Without a stack trace, it's guesswork. You must either use a remote debugger (usually not an option at the customer's site) or rely on debugging messages. In terms of giving Joe End-User an error message, forget it. You don't even know what the problem is.

An example

Imagine you're in charge of developing an application to manage and configure a security system, which includes several kinds of remote sensors, cameras, and other devices. Each device type has unique configuration commands. Each type reports security information. Information about these devices must be persistent (stored in a database), such as the physical location of the devices, their configuration information, the IP address of the devices, and so forth. Finally, all of the devices must be managed from a remote user interface. This entails configuring the devices, presenting information generated by the devices, and storing information about them.

  • Print
  • Feedback

Resources
  • Previous JavaWorld stories on exception handling