Web hosting shopping cart - JavaSercer Pages you get the response shown in
JavaSercer Pages you get the response shown in Figure 7.3. Figure 7.3. Debug output Since the debug parameter specifies both resp and stdout, you also get all the debug information in the window where you started Tomcat. 7.3 Dealing with Runtime Errors Eventually, your application will work as you like. But things can still go wrong due to problems with external systems that your application depends on, such as a database. And even though you have tested and debugged your application, there may be runtime conditions that you didn’t anticipate. Well-behaved components such as JavaBeans or JSP actions (standard and custom) deal with expected error conditions in a graceful manner. For instance, the UserInfo bean used in Chapter 5 has a valid attribute that is false unless all properties are set to valid values. Your JSP page can then test the property value and present the user with an appropriate message. But if something happens that makes it impossible for the component to do its job, it needs to tell the user about the problem. The standard way Java does this is to throw an exception. That’s what the JSP container does when it finds a problem with a JSP page during the translation phase, as I described in the first section of this chapter. Components, such as JavaBeans and JSP actions, and the code in JSP scripting elements, can also throw exceptions when something goes really wrong. By default, the JSP container catches the exception and displays its message and stack trace in the browser, similar to what’s shown in Figure 7.1. But that’s hardly the type of error message you want the application users to see. It’s better to tell the JSP container to use a customized error page instead. page 83
Hint: If you are looking for very good and affordable webspace to host and run your j2ee hosting application check Sandzak.com j2ee web hosting services