1 Replies - 1238 Views - Last Post: 02 February 2011 - 02:32 AM Rate Topic: -----

#1 tsotne1990   User is offline

  • D.I.C Head

Reputation: 0
  • View blog
  • Posts: 230
  • Joined: 01-November 10

Structured Exception Handling

Posted 01 February 2011 - 05:38 PM

Hello! Im reading the SEH topic in a book and encountered a part of that topic that is very briefly examined and couldn't understand everything. Could you possibly explain how to use this code and what does it mean and how does it differ from the ordinary custom exception handling?
Thank you


Now, based on your current background with .NET, you may have no idea regarding the role of
attributes or object serialization, which is just fine. I’ll address these topics later in the text (see Chapter
15 for information on attributes and Chapter 20 for details on serialization services). However, to
complete our examination of building custom exceptions, here is the final iteration of
CarIsDeadException, which accounts for each of these special constructors:

public class CarIsDeadException : ApplicationException
public CarIsDeadException() { }
public CarIsDeadException(string message) : base( message ) { }
public CarIsDeadException(string message,
System.Exception inner)
: base( message, inner ) { }
protected CarIsDeadException(
System.Runtime.Serialization.SerializationInfo info,
System.Runtime.Serialization.StreamingContext context)
: base( info, context ) { }
// Any additional custom properties, constructors and data members...

This post has been edited by Tsotne: 01 February 2011 - 05:40 PM

Is This A Good Question/Topic? 0
  • +

Replies To: Structured Exception Handling

#2 [email protected]   User is offline

  • D.I.C Addict
  • member icon

Reputation: 1003
  • View blog
  • Posts: 975
  • Joined: 30-September 10

Re: Structured Exception Handling

Posted 02 February 2011 - 02:32 AM

Well the first three constructors are self explanatory I think. The first one is a default constructor, the second allows a string message to be passed. The equivalent contructor of the base class is then called (using :base()). This is done as, by default, the default constructor of base class is called when an instance of the subclass is created. However, we want the base type to be initialized properly, hence we tell it to use a the corresponding constructor in the base class.

The third constructor passes in a message and the inner exception and then calls the corresponding base class constructor using :base() again. All pretty standard contructors that you would associate with every exception class.

Now, this constructor:

protected CarIsDeadException(
System.Runtime.Serialization.SerializationInfo info,
System.Runtime.Serialization.StreamingContext context)
: base( info, context ) { }
// Any additional custom properties, constructors and data members...

is just to provide serialization support. Exception classes should be serializable (and, as such, all the exception class will have a constructor like that) as they should be able to be passed across application domains (app domains hold .NET executables and they may be multiple App domains in a single Window's process), different processes etc. Also, they may need to be passed across remoting boundaries, logged to databases etc etc.

That constructor is called automatically during the deserialization process. Say you have serialized the exception, when it comes to 'putting the object back together again', that constructor is what the runtime uses to recontruct the object. Notice how it is 'protected', this means that you cannot directly use/see that constructor when creating an instance of the exception, only sub classes can call it. This should reinforce the fact that this constructor is called during automatically deserialization and not directly by you when creating an instance. Note that if the class was sealed (i.e. couldn't be derived from, you could just make the contructor private).

Further, in many custom exception classes, you may see an explicit definition of the GetObjectData() method which is called automatically during the serialization process. In your class, you will inherit a virtual definition of GetObjectData() as the Exception base class (from which all exception classes ultimately derive!) implements the ISerializable interface which means it has a definition of GetObjectData(). If you wanted to customise the serialization process, you would provide your own definition of GetObjectData() in your exception class too (as well as probably implementing the ISerializable interface directly).

My suggestion is to read up on serialization and look particuarly for reading regarding customising the serialization process and/via implementing the ISerializable interface (as well as the general members that exception classes have (Message property, etc). I think that once you have read up on that, you will realise that the definition you provided is just a snippet of a bog standard custom exception class. It's nothing particuarly special, it is just a custom exception :).


A few useful starting points, in addition to your book:




Good question though, as it does seem a bit obscure the first time without any explanation :).

This post has been edited by [email protected]: 02 February 2011 - 06:14 AM

Was This Post Helpful? 1
  • +
  • -

Page 1 of 1