Global Error Handling and Remoting
Although the remoting technology is kind of sun setting in favor of WCF and ‘netTCPBinding’ there are numerous enterprise applications that are heavily dependent upon remoting for their application tier. And I'm working with one such application, rather a huge one. We have a app and web tier and they communicate using remoting(IIS hosted). We ran into a situation where we have to trap all the un-handled exceptions on the app tier and log it + return a more generic exception back to the presentation tier. We return a more generic exception because we don't want the details of the original exception to bubble up the stack for security purposes - hide the exception details from the web tier, which will normally be in the DMZ, and reduce the attack surface area.
Trying and logging errors in ‘global.asax’, ‘application_Erorr’ (assuming the remoting is hosted in IIS, the popular way) event will not work because of the way the ‘System.RemotingHandler’ that handles IIS remoting is set up.
So based upon the requirements which is
- Trap original exceptions and log it
- Return a more generic exception to the web tier and swallow the original exception
One easy solution would be to wrap every call in the public interface with a try, catch block and this seems to be the most popular Google solution. Frankly that’s how I have been doing thus far and it goes back to 4+ years of using remoting(this solidifies my wife’s belief that I’m a dumb techie). But we were in a situation where we did not have the luxury of time to wrap every call and test every call as the app was pretty big.
So we were in a bind to come up with something other than the laborious try-catch solution. After few hours of mucking around in Reflector I was able to find a cooler and elegant solution and here it is. You need to do 2 things
- Turn on <customErrors> mode to ‘off’ under the ‘system.remoting’ section (and not the one under ‘system.web’, this one has no effect on remoting calls) in web.config. This will ensure that you report back the original exception back to the web tier and not the generic remoting exception which is the default behavior.
- Have a server side sink to trap and log the exception + transform the specific exception to a more generic exception.
-
The bulk of the code to do the post processing will be right after the call to the ‘processMessage’ (line 77). When the call returns it would have executed the actual remoting function call and in essence we are doing post processing.
-
‘returnMessage.Exception’ (line 87) gives you a handle on the original exception that was generated. If it is not null then it means the actual remoting function call has generated an exception. If so log the original exception.
-
To transform the original exception to a more generic exception we need to instantiate(line 92) a new ‘ReturnMessage’ with a generic exception of our choice and let it bubble up the call chain.
Voila!! With this pattern we have satisfied all of the original requirements. More importantly this eliminates the need for the spaghetti try-catch blocks and even better we have eliminated all the overhead associated in wrapping bocks with try-catch. This model will also work for other remoting hosting options.
Honestly, I wish I had found this earlier and not after 4 years of spaghetti coding. Again it validates the fact that when you are in dire needs you tend to think laterally!!
In the near future I will also post some sample as to how to globally handle WCF errors using the same requirement.