i recommend you don't wrap entire pages/functions in try catch blocks, they should be used granularly i.e. wrap them around the individual instruction(s) that may fail. If there is an error in an area that's not wrapped up in a block it will bubble up scope, first to any enclosing block such as sub/function, then to the page, then to the application. If you want a "catch-all" at page level, better to add a delegate to a function or use the page_error event.

Cathal

Hi Sergey,

Maybe a bit more context would be useful.  Are you actually catching an exception during every httpModule call?  If so, that's not really an exceptional circumstance and you should handle the erroneous occurrence during your normal code flow.  Have you tried benchmarking with a release build?  What were the speed differences?

Here's another bit of advice that will probably cause some controversy: don't catch the base exception class (catch ex as System.Exception).  I wonder if that's not what you're already doing, and possibly obscuring some unanticipated exceptions.

Finally, don't wrap your entire method in one big Try-"Catch Exc as Exception" monster.  I know of one unnamed awesome application that does this all the time, and it drives me crazy!

Brandon

Cathal is correct to a degree in that Try/Catch in itself is not slow.

However, processing an exception is slower than having no exception.  So in summary. from slowest to fastest we have:

1. Do not handle exception
2. Handle the exception with Try/Catch
3. Rewrite your code to avoid exceptions

If you find that you are getting an exception raised consistently then your code should be rewritten to avoid the exception. 

For instance, if you are getting a null reference exception from trying to access a property or method of a null object, then rather than use try/catch you should use -- if (object != null).  This would be much faster.

I realise that this is not always possible.