Programming Jakarta Struts, 2nd Edition [Electronic resources] نسخه متنی

اینجــــا یک کتابخانه دیجیتالی است

با بیش از 100000 منبع الکترونیکی رایگان به زبان فارسی ، عربی و انگلیسی

Programming Jakarta Struts, 2nd Edition [Electronic resources] - نسخه متنی

Chuck Cavaness

| نمايش فراداده ، افزودن یک نقد و بررسی
افزودن به کتابخانه شخصی
ارسال به دوستان
جستجو در متن کتاب
بیشتر
تنظیمات قلم

فونت

اندازه قلم

+ - پیش فرض

حالت نمایش

روز نیمروز شب
جستجو در لغت نامه
بیشتر
لیست موضوعات
توضیحات
افزودن یادداشت جدید








10.3 System Versus Application Exceptions


Exceptions can be further classified into either
system
exceptions
or application exceptions.
System exceptions are more serious in nature. These are typically
low-level problems that aren't related to the
application logic and from which end users are not expected to
recover. In many cases, system exceptions are unchecked, and your
application isn't supposed to catch them because
they are either non-programming errors or are so severe that nothing
can be done about them.

Application exceptions are errors that occur because of a violation
of a business rule or some other condition in the application logic.
For example, you might throw an application exception when a user
attempts to log in to the application but the account has been
locked. This isn't a catastrophic error, but it is a
problem that needs to be reported and handled.

Within Struts applications (and web applications in general), there
are essentially two approaches you can take when an exception occurs.
If the exception is an application exception from which the end user
may be able to recover, you typically want to return control back to
the input page and display a user-friendly statement of the problem
and some action that can be taken to resolve it. Continuing with the
locked account example, you could throw an
AccountLockedException back to the action class,
which would forward control back to the login page and inform the
user that the account is locked.

If the thrown exception is a low-level exception such as a
RemoteException,
the only meaningful action the application can take is to display a
system error page. There's nothing the user can do
to fix the problem. It may be a programming error or some type of
network issue, but the point is that you don't want
to let the user see the stack trace of the exception. Instead,
forward to a system error page that's more
user-friendly to look at and optionally informs the user to notify
the system administrator. The exception should also be logged to aid
the developer in determining the root cause of the problem.

Later in this chapter, you'll see examples of how to
return control back to the input page and show a localized message to
the user. You will also learn ways of dealing with system errors by
forwarding control to a system error page, all of which will add
value to the application and to the user experience.


    / 181