jsJSP best practices
Follow these tips for reusable and easily maintainable JavaServer Pages
Summary
This article discusses simple approaches and best practices that, when used correctly, facilitate JavaServer Pages (JSPs) development. These tips ensure reusable and easily maintainable JSPs, JSPs that allow developers to focus on their programming strengths. (3,000 words; November 30, 2001)
By Dustin Marx
JavaServer Pages (JSPs) technology is an extension of Java servlet technology and combines HTML and Java code into a single file. While Java servlet technology focuses on Java classes capable of generating HTML output with PrintWriter.println() statements, JSP technology abstracts this concept to a higher level. With JavaServer Pages, a Web developer can write static HTML pages and simply add Java code in those sections of the page that need to be dynamically generated. While this flexibility enables rapid development of simple Web applications, it can be abused, resulting in unnecessarily complex applications that are difficult to maintain, reuse, and enhance.
To avoid needlessly complex applications, follow the practices I present in this article:
1. Separate HTML from Java
2. Place business logic in JavaBeans
3. Factor general behavior out of custom tag handler classes
4. Favor HTML in Java handler classes over Java in JSPs
5. Use an appropriate inclusion mechanism
6. Use a JSP template mechanism
7. Use stylesheets
8. Use the MVC pattern
9. Use available custom tag libraries
10. Determine the appropriate level of XML compliance
11. Use JSP comments in most cases
12. Follow HTML best practices
13. Utilize the JSP exception mechanism
These tips will help you write JSPs that are reusable and easy to maintain.
Separate HTML from Java
It can be tempting to throw all Java and HTML code necessary for a Webpage into a single JSP file. In simple system development, such an approach makes it easy for someone new to the system to locate all relevant code in one place and understand how it all interacts. However, this approach becomes burdensome and costly when the application grows more complex and more developers become involved.
Combining HTML and Java in the same source code can make the code significantly less readable. To enhance software readability, developers often use indentation; but mixing HTML and Java scriptlets in the same file can make useful indentation extremely difficult to maintain.
Many Web development methodologies and architectures now emphasize the separation of HTML from Java code so different developers can focus on their strengths. Properly separating Java and HTML, including HTML-like JSP tags and custom tags, allows Web designers and HTML coders to work on the HTML (presentation) aspects, while Java developers work on the application′s Java (processing logic) portions. Java developers focus on business logic as they implement the behavior behind the custom tags; Web designers then use these custom tags just as they use ordinary HTML tags.
Applications with Java properly separated from HTML are more reusable because the Java components are not tied to a Web browser and can be used by other parts of the application. In addition, maintainability is enhanced because of the increased modularization that comes from Java/HTML separation.
Placing business logic in JavaBeans also promotes stronger applications. I′ll explain how next.
Place business logic in JavaBeans
Java code included directly inside a JSP is not as readily accessible to other JSPs as Java code contained within a JavaBean. Common behavior and business logic placed in JavaBeans can not only be used by other JSPs but also by other portions of the application. That is because JavaBeans are merely Java classes that satisfy some basic conventions (such as a constructor with no arguments and public get/set methods for private data members) and can be used as any other Java class. Note that Enterprise JavaBeans (EJBs) are also useful for storing behaviors and data common to all components of the application.
Factor general behavior out of custom tag handler classes
Java classes known as custom tag handlers implement custom tags. Unlike JavaBeans, custom tag handler classes are not readily used like ordinary Java utility classes. Instead, custom tag handler classes implement specific interfaces -- or extend classes that provide these interfaces′ basic implementations. Because they are not readily reused outside JSPs, custom tag handlers should contain only specific behavior that would not be useful outside that custom tag -- that is, outside the JSP. Custom tags often require support for common behaviors or business logic and can utilize JavaBeans or EJBs that perform those common behaviors.
Favor HTML in Java handler classes over Java in JSPs
Sometimes cleanly separating HTML, JSP tags, and HTML-like custom tags from Java requires unnecessarily convoluted code. In these cases, you either include Java scriptlets and expressions in the JSP or put some HTML code in the Java tag handler class. I′d rather see a small amount of HTML code in the Java class than see Java, such as scriptlets and expressions, in the JSP. Since custom tag handlers are specific to the custom tags they implement (and not reusable outside JSPs), placing necessary HTML there is not troublesome. Sun′s Java 2 Platform, Enterprise Edition (J2EE) Blueprints documentation discusses this issue further.
There are exceptions to this standard: if including one or two lines of Java code as scriptlets in the JSP solves the same problem that would require many more lines of HTML in the Java handler class, allowing Java code to exist in the JSP page might be prudent.

Use an appropriate inclusion mechanism
It is rarely good design to reproduce code commonly used by different application pieces each time another piece of that application needs that functionality. Factoring common JSP or HTML code out of multiple pages and into a single file improves maintainability (you need to make changes in only one location) and reusability.
Two JSP include mechanisms reduce code redundancy and promote reusability; to ensure that you use the appropriate include mechanism, it is important to know the differences between the two. Generally, I use the include directive unless I can justify a need for the include action. Question 7 in the Blueprints′ "Web Tier" section provides a good resource for understanding the differences between the two include mechanisms and determining which to use in a particular situation.
Include directive
A JSP′s include directive includes the content of a specified file in that JSP. Use the include mechanism for situations when text, such as ASCII or HTML, needs to be included in multiple JSPs. For example, I commonly use the include directive to include footer information, such as company name or copyright date, on every JSP in a company′s application.
Since you include the content of any file specified by the include directive in the calling JSP before it compiles, variables and other values specified in the calling JSP can also be utilized in the included content. However, I try not to rely on variables defined in the calling JSP, since this dependency reduces the included file′s reusability.
Include action
The include action executes the specified JSP first and then places the generated response in the calling JSP. Because the include action includes the generated response rather than the source content itself, variables and other values specified in the calling JSP are not available to the page included with the include action.
One disadvantage of the include action as currently implemented by the JSP implementations with which I am familiar relates to the flush="true" attribute. In the JSP implementations I have used, this attribute is required and must be set to true. The true value indicates that the buffer will always flush before a target page specified by the include action executes. This can prove problematic if the forward mechanism is invoked either explicitly or implicitly later in the JSP. In the recently released JSP specification (1.2), however, the include action′s flush attribute can be set to false. Tomcat 4.0 provides a reference implementation of this specification and supports this new include action argument.
Use a JSP template mechanism
A template mechanism allows for a common file to control Webpage, or JSP, layout. Then, when you want to change the layout, you need to modify only one file, and all the other pages will reflect the layout change. This doesn′t just make for more maintainable code; using templates to control layout also makes Webpages more aesthetically pleasing to users who see consistent layouts for all an application′s pages.
I use Struts′ custom tag template library as a template mechanism. David Geary′s article "JSP Templates" provides a good starting point for looking at using templates with your JSPs.
Use stylesheets
Just as templates enable developers to place layout control in a single location, stylesheets enable developers to place appearance control in a single location. I use Cascading Style Sheets (CSS) to control such items as font families, font sizes, and table characteristics. Like templates, stylesheets allow the developer to make changes in one location; those changes immediately reflect on all appropriate pages, resulting in increased maintainability and consistent appearance to users.
Use the MVC pattern
While other design patterns can be used effectively with JSPs, I often use the Model-View-Controller (MVC) architecture with JSP technology. MVC enables the development of applications that are easier to create, test, maintain, and enhance. In JSP terminology, implementation of an MVC architecture is often referred to as Model 2 (from an early JSP specification). The J2EE Blueprints samples are based on MVC.
See "E++: A Pattern Language for J2EE Applications, Part 1" by Bin Yang, and "Understanding JavaServer Pages Model 2 Architecture" by Govind Seshadri, for more information on JSPs and MVC.
Struts
Struts is an open source MVC implementation (it′s a Jakarta subproject available through the Apache license) that provides base controller functionality that you can extend and enhance in your own applications. The base controller is implemented as a Java servlet, and its configuration is controlled by an XML file called struts-config.xml. When a Struts-based JSP Web application is created correctly, most changes in flow control are made in the struts-config.xml file rather than in the code itself.
Implementing an application that is MVC-compliant involves extra initial effort, but the investment in time up front is worth the rewards of more maintainable and reusable code. Plus, Struts significantly reduces the preliminary work involved in implementing MVC.
Besides supporting MVC implementations, Struts also provides some valuable custom tag libraries, such as the template tag library mentioned previously. The logic tag library has custom tags for iteration and tags for if-then-else structures. The HTML tag library features many useful custom tags, including custom tags for FORM tags and form item tags used in Struts′ form handling and validation. See the Struts documentation for more details on these libraries and other Struts custom tag libraries. I′ll discuss the advantages of using these libraries next.
Use available custom tag libraries
Why should developers spend time reinventing the wheel and worrying about testing and debugging when custom tag libraries are readily available for many different purposes? Some vendors provide custom tag libraries to their customers for free or for individual purchase, but many custom tags can be found online. Resources provides a good starting point for locating potentially useful tag libraries.
While these third-party custom tag libraries occasionally have bugs, most likely such problems will be discovered, since many developers use these libraries and test them in their own applications. Also, many custom tags are open source, so you can edit them to meet your needs.
I find it well worth my time to keep informed of available custom tags, since these libraries often provide functionality common to most Web applications. While learning about available custom tag libraries requires a small time investment, reusing already-available custom tags saves the time of writing, testing, and debugging my own custom tags. As mentioned above, many tag libraries are also open source; in these cases, I can readily adapt general behavior to my specific project′s situation.
Determine the appropriate level of XML compliance
Most JSP developers use shorthand syntax for JSP tags rather than XML syntax. This is partially evidenced by Sun′s JavaServer Pages Syntax Reference, which lists only the tags′ shorthand form.
An advantage to using a 100 percent XML-compliant JSP, including syntax for JSP tags, is that XML validation tools can validate the JSP. XML tools can validate the JSP against a DTD (document type definition) that enforces standard JSP syntax rules.
However, at present writing and maintaining JSPs with XML tag syntax often involves far more effort than the rewards justify. As tools are developed that automatically convert shorthand syntax to XML syntax, the benefits of XML-compliant JSPs will likely make the reduced effort worthwhile. I have waited for the JSP specification and its implementations to mature in relation to XML-compliant JSPs before fully utilizing XML-compliant tags. See the sidebar below, "XML in the JSP Specifications," for more information on how XML compliance is handled in the latest JSP specification.
I am not implying that you cannot currently use XML with JavaServer Pages technology. I simply prefer to wait for better tools to manage the JSP-to-XML mapping as outlined in the 1.2 specification before pursuing XML-compliant JSPs (also called JSP documents). There are, however, other ways the two technologies can be used together. See Resources for articles on using XML with JSPs.
Be sure to keep abreast of the latest JSP specification and the tools your preferred vendors provide that implement that spec′s new features, such as JSP-to-XML mapping. Apache provides Tomcat 4.0 as a reference implementation of the JSP 1.2 Specification.
Use JSP comments in most cases
Appropriate commenting seems to challenge software developers. JSPs, like other types of code, should include comments that describe complex or extraordinary functionality, the pages′ purpose, and other general information typically commented out in source code.
Since JSPs allow developers to intermix Java, JSP tags, and HTML tags in the same page, there are multiple ways to comment a JSP page. Developers should carefully consider which type of comment to employ in the page. HTML comments will be viewable in the compiled JSP′s HTML source code, and both major browsers make viewing this source easy. JSP comments, on the other hand, are not placed in the HTML document created by the JSP compilation process. These comments cannot be viewed as part of the page′s source through the browser, and they do not increase the size of the rendered page′s generated source. Java comments can also occur in a JSP inside Java scriptlet sections. These are not viewable in the browser either, but including Java comments in the JSP page violates the principle of separating Java from the HTML.
Code comments are usually meant for developers who write and maintain code. Therefore, use JSP comments unless there is a compelling reason to have the comments display in the browser upon request.
Note that you should not place sensitive data in JSP source code, not even inside JSP comments. Although the text inside JSP comments is not compiled into the source used to render the Webpage, Web servers might allow users to view JSP source code. Place sensitive data in a database, where access to the data can be controlled and monitored using triggers or other database mechanisms.
Follow HTML best practices
When Java is factored out of the JSP and into JavaBeans and custom tag handlers, the JSP consists mostly of JSP tags, including custom tags, and HTML tags. To make the JSP easier to understand and maintain, follow best practices related to HTML development.
One HTML best practice I follow: include closing tags recommended by the HTML specification even when the browsers do not require them. Most HTML generation tools will match opening tags with corresponding closing tags, but hand-typed HTML documents often lack closing tags (note that there is a small set of HTML tags that lack closing tags). Browsers usually render the page despite missing closing tags, but don′t count on the browser to work correctly when standards are violated. Some missing closing tags, such as </table>, can dramatically affect a page′s rendering in the browser. In addition, you should avoid using deprecated HTML tags, and use lowercase letters for all HTML tags.
The W3C (World Wide Web Consortium) has some resources related to HTML best practices and validation.
Utilize the JSP exception mechanism
While a thrown exception′s stack trace proves extremely useful for developers when debugging their code, it is rarely desirable to share an entire exception stack trace with the software′s users. Lengthy stack traces are not aesthetically pleasing and can increase security risks by exposing information that does not need to be released. JSPs allow developers to catch and handle exceptions in the code, resulting in more secure and aesthetically pleasing exception handling. See Resources for details on the mechanics of JSP exception handling.
Exception information is more useful if information besides the stack trace is included. JSPs can use session variables to store information about the current page and current operation being performed. Then, if an exception does occur, the exception page will be called; it will have access to both the thrown exception and the information about the original page that caused the exception. The exception page can utilize underlying Java code, in JavaBeans or EJBs, to store in the database the complete exception information, related session information, and the exception′s date and time.
To reduce the unsightly error messages printed to the screen and improve security, the exception page need only print out a simple error message and perhaps an identifying number that allows developers to locate more detailed exception information in the database. For aesthetic and security reasons, I prefer storing most of the exception information in a database or flat file rather than printing it all to the screen. Storing the exception information in a database or flat file also allows the information to be persisted even when a user exits the application. Note that during development you should print full exception information to the screen for regular testing and debugging.
Now start developing JSPs
If abused, many JSP conveniences can lead to unnecessary complexity. This article summarizes some JSP practices that allow developers to take advantage of these conveniences without triggering unnecessary complexity. By following the best practices discussed here, you will increase your software′s maintainability and reusability as well as its aesthetic qualities.
Situations might arise where the overhead of some of these recommended JSP practices is not worth the cost, such as in extremely simple applications. However, my experience is that even the simplest applications often evolve into more complex systems. In most cases, the sooner you follow best practices such as these, the better


Jsp最佳实践


原作者：By Dustin Marx
原出处：http://www.javaworld.com/javaworld/jw-11-2001/jw-1130-jsp.html

摘要：这篇文章讨论简单的途径和最佳实践，正确的使用使jsp的开发更为容易。这些技巧确保编写可重用、易维护的jsp。

Jsp技术是servlet技术的扩展，结合html、java代码于一个文件。Java servlet技术关注于利用PrintWriter.println()语句产生html输出的java类，Jsp将这个概念抽象到一个更高的层次。使用jsp，web开发者可以写静态的html和将java代码片段加入到需要动态产生的页面中，从而，这种灵活的技术使简单web应用的快速开发成为可能。然而它能被滥用，从而形成难以维护、重用和改进的不必要的复杂的应用软件。
遵循以下提示的技巧可以避免这种不必要的复杂应用。
1、 分离html和java
2、 将业务逻辑放在javaBean中
3、 从标签定制管理器类中分离出常用行为
4、 较之java代码在jsps中，更倾向于html在java管理器类中
5、 使用适当的包含机制
6、 使用jsp模版机制
7、 使用CSS样式表
8、 使用MVC模式
9、 使用有效的标签定制库。
10、 确定适当的xml依从度
11、 尽可能多使用jsp注释
12、 遵循html最佳实践
13、 利用jsp异常机制
这些可帮助你写出可重用、易维护的jsp

一、分离html和java
将一个web页的所有必须的java、html代码放入一个jsp文件中是诱人的。这种方法使初学者定位相关联的代码和理解它们如何相互作用变的容易。然而，当应用变的更加复杂、开发者变的更加棘手时，这样方式将变的更加繁重和昂贵。
结合html和java在同一的代码来源使程序变的非常不可读。为增强可读性，很多开发者使用缩排格式，但是混合html和java片段的文件使有益的缩排格式变的极其难以维护。
许多web开发方法和机制强调html和java代码的分离，从而不同的开发者可以将精力集中在他们擅长的方面。适当地将java代码和包括jsp标签、定制标签在内的html分离，可以使web设计者、html编写者工作在html（表述）方面，而java开发者工作在应用的逻辑处理部分。当Java开发者实现jsp定制标签后的行为时关注的是业务逻辑，web设计者则象使用普通html标签一样使用这些定制标签。
适当地将java代码从html中分离的应用会更为可重用，因为java组件并不约束于特定浏览器，同时可以运用到应用软件的其他部分。与此同时，源起于java/html分离而增强的模块化也使应用的可维护性得到了提高。
二、将业务逻辑放在JavaBean中
直接包含在jsp中的java代码并不象包含在JavaBean中的java代码那样容易被其他jsp页面理解，通用行为和业务逻辑放在JavaBean中不仅可以被其它jsp，也可以被应用的其它部分使用，这是因为JavaBean仅仅是满足一些基本约定（比如不含参数的构造器，为private类属性设置set/get方法）的java类，也能作为任意其它类使用。值得注意的是，ejb在封装针对应用中所有组件通用的行为和数据时也是有用的。
三、从标签定制管理器类中分离出常用行为
作为定制标签管理器类的java类实现定制标签，并不象JavaBean，它不能如普通java工具类一样易于使用，而是，定制标签管理器类实现特定的接口或继承提供这些接口基本实现的类。由于它们不易于在jsp外使用，定制标签管理器类应当仅包含那些不能在定制标签之外、jsp之外使用的特定行为。定制标签常常需要针对通用行为和业务逻辑的支撑，并利用提供通用行为的JavaBeans和EJBs
四、较之java代码在jsp中，更倾向于html在java管理器类中
有时从java中分离html、jsp标签和如定制标签的html会需要不必要的令人费解的代码，基于此，你要么将java片段和表述放入jsp中，要么将html代码放入java标签管理器类。
较之看到在jsp中作为脚本的java，我更愿意看到在java类中的一小部分html代码。由于定制标签管理器针对它们所实现的定制标签是特定的（同时也不能在jsp之外使用），放入一些html代码不会有什么麻烦，SUN的J2EE蓝皮书对此有更深入的讨论。
对此标准也有例外：如果在jsp中包含一行或两行java代码片段和在java管理器类中包含许多行html代码解决的问题一样，那么允许在jsp中存在java代码应该是明智的。

五、使用适当的包含机制
包含机制在代码重用方面是少有的好的设计。从多个页面中分离出通用的jsp和html代码放入一个文件可以提高可维护性（仅需要在一处改变）和可重用性。
有两种包含机制缩小了代码冗余促进了代码重用。为确保能够使用适当的包含机制，理解它们二者间的不同是重要的。除非我可以证明需要include 动作是正当的，一般地情况下我使用include指令。在蓝皮书“web 层”部分中的第七个问题，对理解两种包含机制的不同和确定在一特定情况使用哪一种提供了很好的资源。
六、使用jsp模版机制
一个模版机制允许一个公用的文件来控制web页、jsp、页面布局。于是，当你想改变页面布局时，你仅仅需要修改一个文件，所有其它的页面将反映出页面布局的改变。这不仅是使代码更加具有可维护性，页面布局模版机制对那些看到所有应用软件页面都协调一致的用户来说，使web页面显得更加美观和友好。
我使用作为一种模版机制的Structs的定制标签模版库，David Geary的文章《JSP Templates》对考虑在你的jsp中使用模版机制提供一个很好的起点。
七、使用CSS样式表
正如模版可以使开发者将页面布局控制放于一处，样式表可以使开发者将外观控制放于一处。我使用CSS样式表来控制诸如字体格式、尺寸，表特征等项目。象模版一样，样式表允许开发者在一处改变，这些改变会立刻映射到所有外观页面，从而促进可维护性和给用户一致的外观。
八、使用MVC设计模式
当然、其它设计模式可以在jsp中有效的使用，而我经常使用模型?视图?控制器（MVC）的体系机构。MVC可以使应用的开发的建立、测试、维护、改进变得更为容易。在jsp术语中，MVC体系结构的现实经常被作为Model2(来自早期的jsp规范)提起。J2EE蓝皮书的例子就是基于MVC模式的。
阅读Bin Yang的《E++: A Pattern Language for J2EE Applications, Part 1》和Govind Seshadri的《Understanding JavaServer Pages Model 2 Architecture》得到jsp和mvc的更多信息。
Struts
Struts是一个开源的MVC实现，它提供了你可在应用中继承、修改的基本控制器的功能。基本控制器是作为一个java servlet的实现，它的配置是由一个叫struts-configxml的文件控制。当一个基于Struts的jsp Web应用建立时，大多数的改动是在struts-configxml文件中的流程控制，而非它本身代码。
实现一个适应MVC模式的应用，需要初期额外的工作。但是，这个前期的投资可以得到更多“可重用、可维护”代码的值得的回报。再者，Struts对实现MVC初期工作的简化也是值得注意的。
除了提供MVC的实现，Struts还提供了一些有价值的定制标签库，比如前面提到的模版标签库。逻辑标签库包含有迭代循环、if-then-else结构的定制标签。HTML标签库是许多有价值定制标签的代表，包括实现form和用于Struts form 处理、效验的定制标签。阅读Struts文档可获得有关这些标签库和其它标签库的更详细的信息。接下来，讨论使用这些标签库的优势。
九、使用有效的标签定制库
当标签库可以容易、有效地使用在多种用途时，开发者为什么还要为重复开发、担心测试、调式而花费时间呢？一些卖方以免费或单独购买的方式为他们的客户提供定制标签。但是很多定制标签库可以在网上找到，这些资源为找到一个潜在的有用的标签库提供一个很好的起点。
当然这些第三方标签库有时候含有bug,自许多开发者在他们的应用开发中使用、测试这些标签时，绝大多数这样的问题极有可能被发现，同时很多定制标签是开源的，你可以根据自己的需要修改它们。
我发现花时间广泛了解定制标签是值得的，因为这些标签库通常提供了大多数web应用的通用功能，而学习这些标签只需要很少的时间投资，重用已有、有效的定制标签可以节约编写、调试、测试自己的定制标签的时间。正如以上所说，许多标签库是开源，由于这些原因，我可以很容易的使通用的行为适应我特定项目的情况。
十、确定适当的xml依从度
绝大多数jsp开发者使用jsp标签的速记语法而非xml语法。这个已在Sun的JSP语法参考中（列出仅是标签的速记形式）得到部分证明。
使用包括jsp标签在内的100% xml依从度jsp的优势是，xml验证工具可以验证jsp文件，以一个执行jsp基本语法规则的DTD为标准。
不过，在当前写或维护一个xml标签语法的jsp需要额外更多的工作，当把速记语法自动地转化为xml语法的工具被开发出来时，使用xml形式jsp的益处将使这些工作减少。我期待着在完全使用xml形式的标签之前，与xml形式jsp有关的jsp规范和实现能能够成熟。你可以阅读《XML in the JSP Specifications》来获得有关xml依从是如何在最新的jsp规范中运用的更多的信息。
我并不是暗示你不能在当前的jsp技术中使用xml，我只不过是期待在1.2版的规范中有更好的处理jsp-xml映射的工具。不过，有其它的方式可以将两种技术在一起运用，可以阅读有关使用xml和jsp的文章资源。
十一、尽可能多使用jsp注释
适当的注释好象是对软件开发者的挑战。Jsp或其它代码理应包含注释以描述复杂特别的功能、页面用途和其它基本信息。
由于jsp允许开发者将java、jsp标签、html标签混合在一个页面中，所以就有了多种注释jsp页面的方法，开发者应谨慎地考虑使用哪一种注释方式。Html注释在经由jsp编译而成的html源代码中是可见的，同时浏览器是我们很容易地看到这些。另一方面，jsp注释并不放在由jsp编译过程创建的html文档中，这些注释不能作为页面源代码的一部分通过浏览器看到。Java注释也可以出现在jsp文件中的java程序段中，它在浏览器中也是不可见的。但是，在jsp中包含java注释违反了分离java、html代码的原则。
注释通常是对写或维护代码的开发者才有意义的。因此，除非有非得需要在浏览器中显示出来得情况，应该使用jsp注释。


十二、遵循html最佳实践
当java从jsp中分解出放入javaBean和定制标签管理器中时，jsp大部分由jsp标签（包括定制标签）和html标签组成。遵循和html开发有关的最佳实践方法以使jsp更易于理解和维护。
W3C有一些有关HTML最佳实践和验证的资源可参阅。
十三、使用jsp异常机制
对调试代码的开发者来说，一个抛出的异常堆栈痕迹是极其重要的，而和软件使用者共享一个完整的异常堆栈信息是极其少有的。冗长的堆栈信息是不美观的，同时由于暴漏了不必要释放的信息而增加了安全风险。Jsp允许开发者在代码中捕获和处理异常。
除堆栈痕迹外的异常信息更为有用。Jsp能使用一个session变量保存当前正在执行的页面和操作的信息。接着，若一个异常产生，异常页面将被调用，它将同时访问抛出的异常信息和产生异常的起始页面的信息。异常页面可以使用接下来的在javaBean或ejb中的java代码将完全的异常信息、会话信息、异常的日期时间信息存入数据库中。
减少可见的错误信息打印到屏幕同时提高安全性。异常页面仅仅打印出简单的错误信息和可能的鉴别码，而能使开发出在数据库中找到更详细的异常信息。因为美观和安全的理由，我更愿意将绝大部分的异常信息保存进数据库或平面文件而非全部打印到屏幕上。这样同时可以使异常持续存在，甚至是在用户退出应用程序时。注意，在开发期间为了正常的测试和调试，您应当在屏幕上打印出全部的异常信息。