I've just done some tests using .NET remoting to access data on a remote server. As you may know, remoting requires all objects that pass across an application boundary (e.g. between two computers that obviously can't share the same object directly) to be able to be serialized and deserialized in order to deconstruct themselves on one side of the application boundary and then reconstruct themselves again once they've crossed over.
Consequently, if an exception is thrown on the server, it needs to be able to be serialized on the server machine, sent across the network to the client machine, where it must be deserialized again.
PgSqlException cannot currently do this, so if for example a database problem occurs on the server, and the server decides to throw a DavesServerException, and this DavesServerException tries to contain the offending PgSqlException as its inner exception, the top level exception cannot get through to the client for proper handling.
For automatic handling of serialization and deserialization, you will need to add the following constructor and override the following method to PgSqlException:
Code: Select all
// this is the missing constructor from PgSqlException that will allow
// deserialization (and thus remoting) of the exception to work.
protected PgSqlException(SerializationInfo info, StreamingContext context) :
base(info,context) {
someStringField = info.GetString("m_someStringField");
otherIntField = info.GetInt32("m_otherIntField");
}
// if a PgSqlException doesn't contain any special fields beyond those of
// the base Exception class then you don't need this override method.
// This is just provided in case you DO have extra fields to serialize.
public override void GetObjectData( SerializationInfo info, StreamingContext context ) {
info.AddValue("m_someStringField", someStringField, typeof(String));
info.AddValue("m_otherIntField", otherIntField, typeof(Int32));
base.GetObjectData(info,context);
}
Cheers,
Dave W.