[ Team LiB ] 10.7 Bean Errors The
[ Team LiB ] 10.7 Bean Errors The most common problem when using a bean within a JSP is that introspection tends to mask programmer exceptions, making it difficult to see where the problem really is. If a set method throws an exception, the JSP engine will likely print out something cryptic: java.lang.reflect.InvocationTargetException at com.sun.jsp.runtime.JspRuntimeLibrary.introspecthelper at com.sun.jsp.runtime.JspRuntimeLibrary.introspect … etc … The easiest way to discover the real problem is to put the bodies of all the set and getmethods in try/catch blocks and have the catch clause dump the exception to System.err. Although this will cause useful debugging information to be generated, it will leave the bean in an inconsistent state. There is no hard-and-fast rule about what to do in such a situation. The set method could leave the property in its last known state, or it could be reset to a sensible default. Another possibility is to throw the original exception. The user will get an error page, but this might be preferable to getting weird results. Perhaps in a future version of the JSP specification, the JSP engine will listen for VetoEvents, in which case a method could fire such an event on receiving an exception. Another potential problem concerns serialized instances. Consider what would happen if a class contained a member of type int, a serialized instance of this class were created, and then the programmer rewrote the class to make the member a String. Even if the deserialization process were able to build something from this, the result would likely not be meaningful. To prevent this problem, all classes and serialized instances have an ID called the serialVersionUID. When an object is deserialized, the ID of the instance is checked against that of the class; if they do not match, an exception will be thrown. The output from the JSP engine in that case would look something like this: java.io.InvalidClassException: SaveableBean; Local class not compatible: stream classdesc serialVersionUID=8221280906864288240 local class serialVersionUID=-8806858158408665433 If a field has changed types, not much can be done about an error like this, and the only option is to recreate all the serialized instances with the new class. However, some changes are more benign. For example, adding a new field or method should not affect the ability to load old data, as long as it is OK to leave the new fields in an uninitialized state after loading. In most classes, the serial version (UID) value is not implicit but rather is computed based on properties of the class. When the class structure changes, so will this value. However, if old serialized instances should still work with a new class, an explicit form of the ID can be provided to make sure the IDs match. In the preceding case, it would be necessary simply to tell the class to use the same ID as the stream found, which could be done by adding the following line to the class: private static final longserialVersionUID=8221280906864288240L; If an ID has changed because new members were added to the class, the new version of the bean could be given a readObject() method to initialize the new fields after loading. [ Team LiB ] Page 195
Hint: If you are looking for very good and affordable webspace to host and run your tomcat hosting application check Sandzak.com tomcat web hosting provider