5 Tips on Exception Handling, Remoting
Learn to manage your objects' resources, handle event callbacks, and more.
by Richard Grimes

VSLive! San Francisco, February 13, 2003

Note: Richard Grimes is presenting "Exception Handling in .NET" and "Implementing .NET Remoting" at VBITS San Francisco, Thursday, February 13. These tips are from that session.

Exceptions
1. Get into the habit of using Try/Finally to manage your objects' resources: If your object has a Dispose or Close method, call it in the Finally handler. You can also assign an object reference to Nothing to indicate that the object should be included in the next garbage collection.

2. The users of your code will not know what an exception is, so make every effort to ensure that exceptions never leak out of your code. Consider providing an UnhandledException event handler to catch exceptions not handled by other code in your application.

Remoting
1. If your remoting client handles an event from a remote object, then the client itself behaves as a remoting server—hence you need an additional channel for the event callback.

2. A remote method call includes the request to the object and the reply. If the method has no return values and the client is not interested in whether the method succeeded, then you can mark the remote method with the <OneWay> attribute. This means that the client thread does not block waiting for the reply, but it also means that it will not be notified if an exception is thrown.

3. Exceptions are serializable and are transmitted along with the return values from a remote method call. The exception caught in the client will have the stack trace of the client and the server.

About the Author
Richard Grimes is a consultant and author specializing in hardcore Microsoft technologies. He is a frequent contributor to industry magazines. Richard speaks at many conferences worldwide and is a .NET MVP. Reach Richard at richard@grimes.demon.co.uk.