Showing posts with label Exception handling. Show all posts
Showing posts with label Exception handling. Show all posts

Saturday, March 25, 2017

Why normal .NET exception handling doesn't work in WCF?

Errors and exceptions are part of our programming life and WCF is no different. So, when we get errors in WCF, we would like to propagate those errors to our WCF client so that they can accordingly take actions. In order to demonstrate this, let’s go through the code of a simple service:
       public int Add(int number1, int number2)
        {
            return number1 + number2;
        }

        public double Divide(int number1, int number2)
        {
            return number1 / number2;
        }        
Both the above methods will perform some calculation and return the result to the client. Let’s say, now for some reason someone sent 2nd parameter of Divide method as 0. 

What will happen? Definitely code will throw an error or say DivideByZero exception. Isn’t it?

Know how to handle this error? Most of the developers will simply decorate Divide method with Try-catch block and throw the exception, similar to our normal .NET exception handling mechanism as shown in below code:
       
public double Divide(int number1, int number2)
        {
            try
            {
                return number1 / number2;
            }
            catch (DivideByZeroException exception)
            {
                throw exception;
            }
        }       
 
This normal exception handling mechanism will not work in WCF world. Now before discussing on WHY, let’s quickly see what is passed from the client:
       
MathClient math = new MathClient();
            try
            {
                math.Divide(10, 0);
            }
            catch (Exception exception)
            {
                Console.WriteLine(exception.Message);
                Console.ReadLine();
            }       
 

Now if we will run this client application, we will land upon such error message:














Now by looking at the error message, we cannot figure out what went wrong as it only mentions it is an internal error :(

Now coming back to the same question, why is this happening like this?

Well, reason behind this is the message format being used by WCF. WCF uses, XML or XML SOAP to communicate with clients. So, even if any exception is raised, it has to be in XML format. Hence normal .NET exception handling mechanism doesn’t work here because the error is not sent to clients in the form of XML.

So, the solution here is Fault Exceptions and rather than throwing a normal .NET exception, we have to throw a fault exception as shown below:
       
public double Divide(int number1, int number2)
        {
            try
            {
                return number1 / number2;
            }
            catch (DivideByZeroException exception)
            {
                throw new FaultException(exception.Message);
            }
        }
       
 

Now re-run our application and we will be able to see proper error message.





On a summary note, we cannot use normal .NET exceptions to propagate exceptions to the client but same can be used within WCF service.

Hope you like this small but very useful tip. Happy learning!

Wednesday, October 16, 2013

Best Practices for ORM

Although everyone puts their complete effort to develop the best software, sometimes bad things happen. But to be on safer side we can take some precautionary measures. Well, today I want to share some of the best practices which needs to be followed while dealing with any ORMs (Object Relational Models). Most of these are common among many of the relational databases.
  1. Exception handling: One should handle only those exceptions which need to be handled, and let all others pass through. For example, if you want to handle a connection issue you should do this by catching the specific exceptions, but don't use a catch all on Exceptions with the clause "just in case" because it may lead to high performance issues.
  2. USING: As many of us know, that USING automatically handles dispose functionality. But this statement doesn’t work all the time, especially in the case of database connections. If you want to try it out, then run some overnight processes using windows services. Although USING handles it most of the time it is always a good practice to close database handles/connections manually.
  3. Prefer compiled LINQ queries: Compiling a query once and executing it several times can lead to high performance gains. Such queries are useful, especially when the same query needs to be accomplished numerous times for innumerable parameters. The syntax for that is: MORE...