Why Reflector is critical and a little WCF Ajax exception handling

 

When I am interviewing Senior .Net developers if they don’t know what Reflector is and what it does I assume they really aren’t that "Senior". I use Reflector in two ways. First and most important to disassemble code, especially Microsoft code, so I can avoid reading often inadequate documentation on how an API can be used. Second is to learn by seeing how other developers have coded different patterns based upon a similar piece of code or architecture I am working on.

The best memory I have of how Reflector helped me is when .Net WCF 3.5 was released to support Ajax and JSON. Knowing a good amount about how WCF worked I wanted to handle Fault Exceptions by providing my own JSON messages back to the client instead of the default JSON Exception message. I read documentation and looked at some Blogs to no avail. I then took the direct approach and went straight to the source, literally, and to my shock and disappointment found that Microsoft had "Sealed" their new WebScriptEnablingBehavior class! While I pondered the merits of starting from the base WebHttpBehavior and writing all that code that the "SEALED!" class provided I finally accepted that wasn’t the best approach. But because, thanks to Reflector, I could see the exact code they used to provide their exception message I could adapt my strategy to make use of what they had done.

 

 

Leave a Reply

x

We use cookies to ensure the best possible experience on our website. Detailed information on the use of cookies on this site is provided in our Privacy and Cookie Policy. Further instruction on how to disable our cookies can be found there.