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 > > > ([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]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
