Exception Talks:

C# could be awesome in Sunday morning but I bet it’s not the good idea to include programming stuffs in holiday schedule. But, what if when you started proceedings from Saturday night to hear something from exception thread, things started getting intrusting meanwhile and you end up on 530 hours of the Sunday morning with both message and data from exception thread.

I was thinking by far that exceptions are end of something that started from a system call. Finally, all you get a dumb message to deal with and to tell end user that something went wrong. Guess I was wrong.

Yes, exception talks. I had a conversation with it last night. Suppose you pass an object in a function that process that object in five steps and change the state of that object proceeding with each step. So if that object is in state A when it passed through a function so you would get it in state F when it returned back to the function call. But state C (chaos may be) carries dependencies that could produce exceptions and if it happens, object cannot proceed to further steps. In this situation object is in state B trying to turn in state C but couldn’t do it due to unavailable resources. Function call will surely end up in catch block. But object changed its state from A to B and I wanted the current state of that object not initial as it passed in that function.

SOL #1 (Pass it as reference to that function not as an object): It was the initial idea that failed within few seconds due to an afterthought that what would happen when that function generates the output object in function definition or not expecting any parameter. Out Parameters were also fell in same category. Since I required a generic solution so SOL #1 had to shift to the holding vault and apply only if I don’t get a proper solution.

SOL #2 (User defined exception classes that throw exception object with current state of object): It led me to final solution (i.e. SOL #3) but still it was not correct as far as performance was concerned because to achieve this I had to create that exception object in catch block and throw it to the function call. So for that function call exception was generating from catch block of State C but not from State C, which was misguiding for that function call. Here holding vault started expecting SOL #2 in it as well.

SOL #3 (Base Exception class itself): The exception class has a property named Data which is the IDictionary collection of two generic object types as key and value. All you got to do is put your object in that dictionary collection of exception object and throw it back to the function call. 

Now I was getting my smile back gradually because if the function executes successfully it returns the object in state F in try block or in some case if it got the exception so the catch block of that function call not only receives the dumb exception message but also the current state of the object. So following was the final snippet:

objectState = B();

try

{

throw new Exception("Dumb Exception Message");

}

catch (Exception ex)

{

ex.Data.Add(1, objectState);

throw ex;

}

This is something that made me empty that holding vault filled from temporary fixes. I am still not sure if it is correct or not and to what extent it’s correct or incorrect. But on this point can hold the proceeding that started last night and go to sleep. It’s better to analyse this idea with fresh mind when I got up some time in Sunday. Thanks a lot programming to ruin another holiday by providing this homework.