Exception handling best-practise

[Jonathan Fuerth <fu...@sqlpower.ca>]

I'm refactoring an existing web application into the Struts MVC
framework, and I'm moving from the implementation planning to the
coding stage now.  Before I act on some potentially poor choices, I'd
like to run some of my ideas past the group:

The Model part of my application, which handles all the SQL database
interaction and business logic, will inevitably encounter semantically
incorrect user input that the ActionForms in the view could not have
known was incorrect (example: invalid username/password on the login
screen).  Some of these semantic errors will result in SQLExceptions
and the like, which the view (JSPs, ActionForms) should not have
visibility to.

My knee-jerk reaction to this problem was to have the controller
(Action class) catch these exceptions and add ActionErrors to the
response, indicating appropriate message keys which the JSP could
display in the user's favourite language.

This seems to break the MVC design pattern though, because now the
controller contains information the belongs to the view (message keys)
and is making decisions that are the responsibility of the model
(handling the exceptions that the model generated).  Or is it, in
fact, the controller's job to do exception handling?  If so, what
mechanism in MVC generates the error message that the user sees?

My current plan of attack is to create a custom exception class for
everything that could go wrong while the model is doing its thing, and
let them pass through my Action classes to the JSPs.  The JSPs will
handle the exceptions by cross-referencing the exception type to a
message key.. and the user will get an error message in their native
language.

The main problem with this approach is that a lot of things can go
wrong in an application, and this will entail a large number of
exception classes.  An ultimate goal of MVC is to keep the application
maintainable as it grows.  A large number of documented exceptions
*seems* reasonably maintainable... but I haven't started coding yet. :)

So, I hope to learn from your experiences.  What have you people done
when a login fails, a database goes away, a resultset overflows, or
other nasty things happen to the business layer?

Thanks!

-- 
Jonathan Fuerth - SQL Power Group Inc.
(416)218-5551 (Toronto); 1-866-SQL-POWR (Toll-Free)
Unleash the Power of your Corporate Data - www.sqlpower.ca

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Exception handling best-practise

[Jonathan Fuerth <fu...@sqlpower.ca>]

On Fri, Feb 22, 2002 at 04:58:28AM -0500, Ted Husted wrote:
> IMHO, the messages and the messages keys belong to the model. The
> controller is simply transferring this data to the view, as it does with
> everything else, like records from a database. 

Aha, that makes perfect sense to me!  Thanks for clarifying that.  I'm
sure I would have worked myself into a real mess while labouring under
that misconception. :)

> In most cases, exceptions can be converted to ActionErrors. I would try
> and do all of this in the Action, so that the view doesn't have to
> "think" about anything. Also, in the Action it is much easier to access
> utility methods to parse the exception for you. A base method for your
> Actions might be able to do everything; so in the main perform, all you
> end up doing is passing back the instant request, ActionError object,
> and the exception. A base method could handle it from there. 

This sounds like a good plan.  Would this base class also be an
appropriate place to acquire a Connection, then make sure it's
released using try .. finally around the call to the subclass?  I'm
getting connections via a getConnection call in my custom LoginSession
class, which I plan to hook up with Poolman later on.

Thanks again for your help.

-- 
Jonathan Fuerth - SQL Power Group Inc.
(416)218-5551 (Toronto); 1-866-SQL-POWR (Toll-Free)
Unleash the Power of your Corporate Data - www.sqlpower.ca

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Exception handling best-practise

[Ted Husted <hu...@apache.org>]

Jonathan Fuerth wrote:
> This seems to break the MVC design pattern though, because now the
> controller contains information the belongs to the view (message keys)
> and is making decisions that are the responsibility of the model
> (handling the exceptions that the model generated).  Or is it, in
> fact, the controller's job to do exception handling?  If so, what
> mechanism in MVC generates the error message that the user sees?

IMHO, the messages and the messages keys belong to the model. The
controller is simply transferring this data to the view, as it does with
everything else, like records from a database. 

The view's only responsibility is to markup the data it receives (which
is really quite enough these days).

In most cases, exceptions can be converted to ActionErrors. I would try
and do all of this in the Action, so that the view doesn't have to
"think" about anything. Also, in the Action it is much easier to access
utility methods to parse the exception for you. A base method for your
Actions might be able to do everything; so in the main perform, all you
end up doing is passing back the instant request, ActionError object,
and the exception. A base method could handle it from there. 

If you are using the nightly build, you might have the controller add a
user-friendly error first, and then post the detail from the exception.
This way everybody is happy. You can do this with 1.0.x too, but the
order in which they are displayed is not defined. Another approach would
be to pass the exception under a known key in the request, as the Struts
JSP tags do, and have your page display the exception message separately
(when there is one). 

-- Ted Husted, Husted dot Com, Fairport NY US
-- Developing Java Web Applications with Struts
-- Tel: +1 585 737-3463
-- Web: http://husted.com/about/services


Jonathan Fuerth wrote:
> 
> I'm refactoring an existing web application into the Struts MVC
> framework, and I'm moving from the implementation planning to the
> coding stage now.  Before I act on some potentially poor choices, I'd
> like to run some of my ideas past the group:
> 
> The Model part of my application, which handles all the SQL database
> interaction and business logic, will inevitably encounter semantically
> incorrect user input that the ActionForms in the view could not have
> known was incorrect (example: invalid username/password on the login
> screen).  Some of these semantic errors will result in SQLExceptions
> and the like, which the view (JSPs, ActionForms) should not have
> visibility to.
> 
> My knee-jerk reaction to this problem was to have the controller
> (Action class) catch these exceptions and add ActionErrors to the
> response, indicating appropriate message keys which the JSP could
> display in the user's favourite language.
> 
> This seems to break the MVC design pattern though, because now the
> controller contains information the belongs to the view (message keys)
> and is making decisions that are the responsibility of the model
> (handling the exceptions that the model generated).  Or is it, in
> fact, the controller's job to do exception handling?  If so, what
> mechanism in MVC generates the error message that the user sees?
> 
> My current plan of attack is to create a custom exception class for
> everything that could go wrong while the model is doing its thing, and
> let them pass through my Action classes to the JSPs.  The JSPs will
> handle the exceptions by cross-referencing the exception type to a
> message key.. and the user will get an error message in their native
> language.
> 
> The main problem with this approach is that a lot of things can go
> wrong in an application, and this will entail a large number of
> exception classes.  An ultimate goal of MVC is to keep the application
> maintainable as it grows.  A large number of documented exceptions
> *seems* reasonably maintainable... but I haven't started coding yet. :)
> 
> So, I hope to learn from your experiences.  What have you people done
> when a login fails, a database goes away, a resultset overflows, or
> other nasty things happen to the business layer?
> 
> Thanks!
> 
> --
> Jonathan Fuerth - SQL Power Group Inc.
> (416)218-5551 (Toronto); 1-866-SQL-POWR (Toll-Free)
> Unleash the Power of your Corporate Data - www.sqlpower.ca
> 
> --
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>