Advanced Exception Handling

A hack I have is to pass in the type to the constructor of the custom exception, but that seems ugly.  Or is that how the TypeInitializationException is actually done?

(Tried using a reflector, but couldn't quite see it, but am not experienced with looking at that)

Not super for performance so make sure isnt thrown a lot but easiest way is maybe this...

class CustomException {
CustomException(exp.val, exp.val, exp.val, val, val, val);
  //custom properties here

  //properties from TypeInitializationException here
}

try {

}
catch(TypeInitializationException exp)
{
   throw new CustomException(exp.val, exp.val, exp.val, val, val, val);
}

OR

instead of trying to inheritate from it, just use composition.

class CustomException {
   private TypeInitializationException typeExp = new TypeInitializationException ();

   //propeties to it here

   //custom stuff here.

}

i showed both and pretty much the only ways to do it because im not sure if you are working with an exception that isnt thrown by you (then use the first) or if you throwing it yourself, use latter.

your are pretty much on track imo

TheLearnedOne,

This is what I am already doing.  (Notice I said that I could just pass the typeName in through the constructor as my hack).


devsolns,

I think that including an exception as a private member inside my exception (your second one) just to get that one field is a worse hack than sending the field into the constructor.  And the first example, is really also just sending stuff in through the constructor.



For the record, the code I have so far, which I feel is a hack is this:

[Serializable()]
public class CustomInitializationException: Exception
{
      // private members that are added on to the base class
      private string typeName;
      private string customField;

      // Base exception only initializes the typeName and the error message
      public CustomInitializationException(string typeName, string customField, string message) : base("Custom Initialization failed: " + message)
      {
            this.typeName = typeName;
            this.customField = customField;
      }

      // Exception that contains an inner exception as well as a message
      public CustomInitializationException(string typeName, string customField, string message, Exception innerException) : base("Custom Initialization failed: " + message, innerException)
      {
            this.typeName = typeName;
            this.customField = customField;
      }

      // more constructors or whatever else goes here....

      public string TypeName { get { return this.typeName; } }
      public string CustomField { get { return this.customField; } }
}

Um you might want to rethink things.  You keep referring to everything as a hack but what on earth are you looking for?  By the way, using a class inside of a nother is an actual concept called composition.  Its a programming paradigm just like inheritence is and provides a great alternative to it.  All your doing is duplicating code instead of composing the same thing from existing.

You either compose the class you need or inherit from in which you implement/override what works for you.  That is it and really not much more to it.



MySuperSpecialDataSet {

     private DataSet _dataset = new DataSet();

}



You would not rewrite the entire dataset class just to incorporate its functioanlity int your class, would you?

No I would not.

But I also would not include an exception as an inner type just to get one string field.  That is not the idea behind composition.

It is not a "great" alternative to inheritance.  It is a different mechanism used for different situations.  Inheritance iw when you want existing functionality, but want to expand it.  That is what I want in this case.

I assumed - and maybe this is incorrect - that the TypeInitializationException, got the type using some mechanism other than manually passing in.  If not then what I have is already the best solution and not a hack, but somehow I doubt that.  Since I noticed that there were constructors for TypeInitializationException that did not take in a string of the typename.

mrichmon,

I cant and didnt assume you where only using it for one string field.  I've never even looked at its interface.  TypeInitializationException could only got its type by explicityly telling it so.  If you looked at the IL youd be able to see that microsoft is calling it and assigning properties the same way you would.

BTW,
Composition it IS absolutely an alternative and most publications i've read refer to it as the same.

"Inheritance iw when you want existing functionality, but want to expand it." ummm, and composition doesnt allow the same!!!???

-Notice the name of the article, read on is good stuff.

**Component-oriented design as an alternative to inheritance**

http://en.wikipedia.org/wiki/Inheritance_(computer_science)#Component-oriented_design_as_an_alternative_to_inheritance.

An alternative way to design the aforementioned system of persons, students, and employees would be to define helper classes Transcript and Job to store the additional information for a student and employee, respectively. Then, each Person object can contain a collection of Transcript objects and a collection of Job objects. This removes the aforementioned constraints:

Well I disagree about composition.  I could point out articles supporting my point of view as well - and not just froma wiki which is information that can be accurate or totally incorrect.  But instead let's just agree to have different opinions on that since it isn't really the point of this question.

>>I cant and didnt assume you where only using it for one string field.  I've never even looked at its interface
Then I respectfully suggest that you shouldn't have commented until doing the research to see that the only difference here IS the one string field that it adds.  It helps to do a little research before making suggestions - just as Ido research before posting a question, or posting suggestions to others.

>>If you looked at the IL
I don't know what IL stands for.  I did try tools that unbuild the dll and show you the code, and noticed that only some constructors took in a string - others did not.  BUt they all offer that field.  So that is what I was wondering how it was done.

very interesting :o)