Is there any way to stop exceptions getting logged to log file?

[Mark O'Driscoll <ma...@eircom.net>]

I am using a filter to trap exceptions thrown by jsps/servlets. In normal
program operation, lots of these exceptions get thrown.
In order to stop 'localhost_log.YYYY-MM-DD.txt' getting clogged, I'd like to
stop exceptions that are handled by the servlet engine from being logged.
Or at least ust havethe exception mentioned rather than the full stack
trace.


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

Re: Is there any way to stop exceptions getting logged to log file?

[Will Hartung <wi...@msoft.com>]

From: "Mark O'Driscoll" <ma...@eircom.net>
To: "Tomcat Users List" <to...@jakarta.apache.org>
Subject: Re: Is there any way to stop exceptions getting logged to log file?


> 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.

Yes, which means that if you can trivially check your parameters before
calling a routine that will throw an exception because of those parameters,
it is "cheaper" than letting the routine throw the exception and then catch
it.

> 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.

To be really blunt, this is exactly the behavior tha the J2EE servers gives
you. The EJBs can be "transaction ignorant" and the overall transaction will
be committed/rolledback as appropriate.

The key here, though, is most of these exceptions shouldn't be "logical"
exceptions (particularly if there are a lot of them), but rather "physical"
exceptions (database full, integrity check error). Exceptions for
circumstances that are basically out of your control.

As a simple example, we have found, at least with a J2EE environment, that
it would be cheaper to, say, check that a user didn't exist in a DB with
simple SQL rather than insert a row dependant on that user and throw the
foreign key exception back. Much better performance.

Regards,

Will Hartung
(willh@msoft.com)




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

Bug?

[Jean-francois Arcand <je...@sun.com>]

Hi Craig,

browsing the Tomcat code, I found something strange:

In org.apache.catalina.core.StandardHostDeployer, when method remove() 
get invoked, fireContainerEvent(REMOVE_EVENT) is never executed (does 
not appear in the code). I have also looked at StandardHost (but this 
class delegate the call to StandardHostDeployer). In order to implement 
JACC the way we discuss it yesterday, should 
the fireContainerEvent(REMOVE_EVENT) be invoked?

Thanks,

-- Jeanfrancois


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

Re: Is there any way to stop exceptions getting logged to log file?

[Mark O'Driscoll <ma...@eircom.net>]

You're right. It is too late!


> > 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.
Disagree. That is just micro managing exceptions. Transactions are the
example of where a wrapper try/catch block around a series of SQL statements
is a much better way to do it than try/catching each one.

Also subsequent non database actions can cause a rollback.

>
> 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.
That is exactly what the filter will do for you. The transaction wrapup in
the filter will ALWAYS be called => less scope for errors.
>
> > 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.
Oh no it doesn't. Otherwise filters could not work. If you put doChain() in
a try catch block, you catch the exception that the jsp/servlet threw.
>
> > 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
> > > (willh@msoft.com)
> > >
> > >
> > >
> > >
> > > --
> > > 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>
> >
> >
>
>
> --
> 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>

Re: Is there any way to stop exceptions getting logged to log file?

["Craig R. McClanahan" <cr...@apache.org>]

On Wed, 24 Jul 2002, Mark O'Driscoll wrote:

> Date: Wed, 24 Jul 2002 09:46:18 +0100
> From: Mark O'Driscoll <ma...@eircom.net>
> Reply-To: Tomcat Users List <to...@jakarta.apache.org>
> To: Tomcat Users List <to...@jakarta.apache.org>
> 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
> > (willh@msoft.com)
> >
> >
> >
> >
> > --
> > 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>
>
>


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

Re: Is there any way to stop exceptions getting logged to log file?

[Mark O'Driscoll <ma...@eircom.net>]

I don't want to get involved in a programming practice debate BUT......

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.

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.

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?

TIA

- Mark

> 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
> (willh@msoft.com)
>
>
>
>
> --
> 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>

Re: Is there any way to stop exceptions getting logged to log file?

[Will Hartung <wi...@msoft.com>]

From: "Craig R. McClanahan" <cr...@apache.org>
Sent: Tuesday, July 23, 2002 10:38 AM
Subject: Re: Is there any way to stop exceptions getting logged to log file?


> On Tue, 23 Jul 2002, Mark O'Driscoll wrote:
>
> > I am using a filter to trap exceptions thrown by jsps/servlets. In
normal
> > program operation, lots of these exceptions get thrown.
>
> To avoid the exceptions getting logged, you'll need to catch them in the
> servlet or JSP itself (which is a much better programming practice than
> letting them flow through), so that the servlet container never sees them.
> Exceptions from servlets and JSPs should not be considered "normal" --
> they are an indication of an error condition that the application should
> have taken care of, but did not.

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
(willh@msoft.com)




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

Re: Is there any way to stop exceptions getting logged to log file?

["Craig R. McClanahan" <cr...@apache.org>]

On Tue, 23 Jul 2002, Mark O'Driscoll wrote:

> Date: Tue, 23 Jul 2002 18:18:42 +0100
> From: Mark O'Driscoll <ma...@eircom.net>
> Reply-To: Tomcat Users List <to...@jakarta.apache.org>
> To: Tomcat Users List <to...@jakarta.apache.org>
> Subject: Is there any way to stop exceptions getting logged to log file?
>
> I am using a filter to trap exceptions thrown by jsps/servlets. In normal
> program operation, lots of these exceptions get thrown.
> In order to stop 'localhost_log.YYYY-MM-DD.txt' getting clogged, I'd like to
> stop exceptions that are handled by the servlet engine from being logged.
> Or at least ust havethe exception mentioned rather than the full stack
> trace.
>

To avoid the exceptions getting logged, you'll need to catch them in the
servlet or JSP itself (which is a much better programming practice than
letting them flow through), so that the servlet container never sees them.
Exceptions from servlets and JSPs should not be considered "normal" --
they are an indication of an error condition that the application should
have taken care of, but did not.

To change how much gets logged when an exception is caught by Tomcat,
you'll need to modify the Tomcat sources.

Craig


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