From: "Mark O'Driscoll" <[EMAIL PROTECTED]> To: "Tomcat Users List" <[EMAIL PROTECTED]> 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 ([EMAIL PROTECTED]) -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
