On Wed, 24 Jul 2002, Mark O'Driscoll wrote:
> Date: Wed, 24 Jul 2002 09:46:18 +0100
> From: Mark O'Driscoll <[EMAIL PROTECTED]>
> Reply-To: Tomcat Users List <[EMAIL PROTECTED]>
> To: Tomcat Users List <[EMAIL PROTECTED]>
> Subject: Re: Is there any way to stop exceptions getting logged to log
> file?
>
> I don't want to get involved in a programming practice debate BUT......
>
Too late ... :-)
> The performance hit from exceptions occur because exceptions are thrown, not
> in how they are handled. You cannot programatically avoid exceptions with
> xhaustive checking that would itself hinder performance. Specifically
> potential SQL errors are <pun>exceptionally</pun> difficult to cater for.
> (dropped connections, network problems, constraint violations) .Exceptions
> are only thrown when something goes wrong. The point I was trying to make
> was that exceptions are not only a sign of system failure, but one of usage
> failure too.
>
Because SQLException is a checked exception, you can't throw it directly
from a servlet anyway, so your database accesses are already encapsulated
in try/catch blocks. You've already paid all the cost of checking
already -- you actually have to deliberately rethrow it (wrapped in a
ServletException) to allow your filter to see it. Why go to all that
extra work?
> Anyway, what I was trying to do was to implement a transaction & logging
> filter that determined if a particular database write operation had worked.
> The code is simple and checks if a servlet/jsp has thrown an exception to
> check for success/failure. If the servlet/jsp completes without throwing an
> exception, I commit the transaction, otherwise I roll it back.
>
This is not the way you should program database applications! It is very
very dangerous to depend on external logic to commit or roll back
transactions for you. If an exception happens, it should be logged and
dealt with when it happens.
Database access logic should always catch its own exceptions, and
commit or roll back the transaction appropriately. In a web app, it is
considered irresponsible programming for a servlet to leave an open
database transaction after it returns from the service() method, for
whatever reason that might happen. To say nothing of returning the
connection to the connection pool you got it from.
> Is there some recognised way to pass servet/jsp error conditions to filters?
> This would prevent me relying on exceptions (altho' exceptions would have to
> be catered for too). I suppose I could use the request.getAttribte()?
>
> Are exceptions that are trapped in a filter 'seen' and handled by Tomcat?
>
Your problem is that Tomcat sees the exception thrown by the servlet
before it is passed back to the filter. That's where the logging is
happening. And that's not going to change (in the standard Tomcat
release -- you're perfectly free to modify your own copy), because
handling exceptions is not what filters are for.
> TIA
>
> - Mark
>
Craig
> > I'll second what Craig has said and add that if your program "normally"
> > throws lots of exceptions, then you should look at some of your design
> > decisions. Exceptions are wonderful when used for "Exceptional" behavior,
> > but not for "normal" runs. They are also REALLY slow. Exceptions can kill
> > your performance, and if you are getting them regularly, you should catch
> > the ones you can "safely" ignore as early as possible and toss them away
> as
> > appropriate, or even better, not throw them at all.
> >
> > Regards,
> >
> > Will Hartung
> > ([EMAIL PROTECTED])
> >
> >
> >
> >
> > --
> > To unsubscribe, e-mail:
> <mailto:[EMAIL PROTECTED]>
> > For additional commands, e-mail:
> <mailto:[EMAIL PROTECTED]>
> >
> >
>
>
> --
> To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
