The "using" construct looks incredibly handy for situations that require both beginning and separated end parts.
Quick example to illustrate:
using (new Tag("body")) {
Trace.WriteLine("hello!");
}
// ...
class Tag : IDisposable {
String name;
public Tag(String name) {
this.name = name;
Trace.WriteLine("<" + this.name + ">");
Trace.Indent();
}
public void Dispose() {
Trace.Unindent();
Trace.WriteLine("</" + this.name + ">")
}
}
The beginning part is defined as the constructor, the end part is the Dispose method.
However despite of being attractive this construct has a serious caveat that comes from the fact that the Dispose method is called from within a finally block. So there are 2 problems:
You should avoid throwing exceptions from the finally block because they will override the original exception that was supposed to be caught.
There is no way of knowing inside of the Dispose method if an exception was thrown earlier between "beginning" and "end" and thus there is no way of handling the "end" part accordingly.
These 2 things make using of this construct impractical which is a very sad fact.
Now, my questions are:
Is my understanding of the problems right? Is this how "using" actually works?
If so, is there any way to overcome these problems and make practical use of the "using" construct other than what it was originally designed for (releasing resources and cleaning up)
In case there is no practical way for "using" to be used this way. What are the alternative approaches (to enforce the context over some code with the beginning and end parts)?
Your rule #1 applies with or without using, so the rule #2 is the real decider: opt for a try/catch if you must distinguish between situations when an exception has been thrown and the normal program completion.
For example, if your persistence layer may discover issues in the process of using a database connection, your connection needs to close regardless of the fact that there was an exception. In this case, the using construct is a perfect choice.
In some cases you can set up using specifically to detect normal completion vs. an exceptional completion. Ambient transactions provide a perfect example:
using(TransactionScope scope = new TransactionScope()) {
// Do something that may throw an exception
scope.Complete();
}
If scope's Dispose is called before Complete has been called, TransactionScope knows that an exception has been thrown, and aborts the transaction.
The intent of the using statement and of the IDisposable interface is for the user to dispose of unmanaged resources. These resources are usually expensive and precious, so they must be disposed of no matter what (that's why it's on the finally). Code in finally blocks can't even be aborted, and it can hang a whole app domain shutdown.
Now, it's very tempting to abuse using for the purposes you're describing, and I've done that in the past. Most of the time there's no danger there. But if an unexpected exception happens, the whole state of the processing is compromised, you wouldn't necessarily want to run the end operation; so in general, don't do this.
An alternative is to use a lambda, something like this:
public interface IScopable {
void EndScope();
}
public class Tag : IScopable {
private string name;
public Tag(string name) {
this.name = name;
Trace.WriteLine("<" + this.name + ">");
Trace.Indent();
}
public void EndScope() {
Trace.Unindent();
Trace.WriteLine("</" + this.name + ">");
}
}
public static class Scoping {
public static void Scope<T>(this T scopable, Action<T> action)
where T : IScopable {
action(scopable);
scopable.EndScope();
}
}
Use it like this:
new Tag("body").Scope(_ =>
Trace.WriteLine("hello!")
);
You can also create other implementations that run certain actions based on whether exceptions were raised of not.
In Nemerle, the language can be extended with new syntax to support this.
I dont know if this was the original intention of IDisposable, but Microsoft certanly ARE using it the way you describe (separating begin and end parts). A good example for it is the MVCForm class, provided by the mvc infrastracture. It implements IDisposable and writes the end tag for the form, while i cant see its implementation releasing ant resources (the writer used there to ouput the html seems to stay alive even after the form is disposed).
Alot has been written about the using block and how it "swallows" exceptions (a wcf client is a good sample, you can also find such discussions here, on SO). Personally i also feel alot of times that as much as it is convinient to use the using block, its not really 100% clear when it should and when it should not be used.
Of course, you actually CAN tell within the dispose method if you reached it with our without an error, by adding an extra flag to your class, and raising it within the using block, but this will work only if the person who will use your class will be aware of that flag
You are correct in observing a problem with the design of try/finally blocks, which is in turn a problem with using: there is no clean way for code in a finally block to know whether code execution will continue with the statement following the finally block, or whether there is a pending exception which will be effectively take over as soon as the finally block executes.
I would really like to see a language feature in vb.net and C# which would allow a finally block to include an Exception parameter (e.g.
try
{
}
finally (Exception ex)
{
...
}
where the passed-in exception would be null if the try block exited normally, or would hold an exception if it did not. Along with this, I would like to see an IDisposableEx interface, which would inherit Dispose, and include a Dispose(Exception ex) method with the expectation that user code would pass in the ex from the finally block. Any exceptions which occurred during the Dispose could then wrap the passed-in exception (since both the passed-in exception, and the fact that an exception occurred in Dispose, would be relevant).
Failing that, it might be helpful to have .net provide a method which would indicate whether there was an exception pending in the current context. Unfortunately, it's not clear what the exact semantics of such a method should be in various corner cases. By contrast, the semantics of finally (Exception ex) would be perfectly clear. Note, incidentally, that a proper implementation of finally (Exception ex) would require that the language make use of exception filters, but would not require exposing the ability to create arbitrary filters.
In my opinion you are misusing the IDisposable interface.
A common practice is to use the interface to release unmanaged resources. Normally, the garbage collector will clean up objects, but in some cases - When yo do NOT longer need the object - you might need to manually clean up.
However in your case, you are not cleaning up an object that is not needed anymore; you are using it to force some logic. You should use another design for that.
Related
I'm in the middle of writing a saving and loading system that saves game objects to a JSON compatible format and loads them back. Saving objects is fine and fairly fool-proof. However, I'm in the process of trying to make the loading process more bullet-proof and easier for me to pin-point errors. Obviously as I'm loading data from a JSON file, everything is being converted from strings, with the potential for all kinds of user error.
Each objects loading method contains something similar to this ---
public void Load()
{
try
{
// Deserialize..
// Potential for all kinds of exceptions, invalid casts, missing info, etc..
// For eg:
bool active = data.GetField("active").Value<bool>();
// GetField() throws an exception if the field doesn't exist.
// Value<T>() throws an exception if it's an invalid cast, etc.
}
catch(Exception e)
{
// ..and those exceptions get caught and logged here.
Logger.LogError(e.ToString, this);
}
}
One of the benefits of catching all the exceptions in the objects Load method is that when 'LogError()' is called with the object as a parameter like shown, it will highlight the offending object in the IDE hierarchy that threw the error (whichever one it may be) making it very quick to find the object with the error and debug it's script or saved data.
Is this an appropriate usage of throwing and catching exceptions, or is there a better design pattern I should be implementing?
Thanks for your time,
Sam
There are always a lot of different but close opinions about catching the exceptions, but for your task the given approach is simple and viable. The only thing I'd recommend for you to do is to allow the exception to bubble up:
catch(Exception e)
{
// ..and those exceptions get caught and logged here.
Logger.LogError(e.ToString, this);
throw;
}
Logging is a good idea, but what should your program do if the loading fails? Just log it out and continue? It can be the case, but this load method looks like important and integral part of your program. It does not look like some background work-that-may-fail-or-work-I-don't-care. Well, its your program and I don't know the requirements or context - just an opinion of mine.
The main principle you should base your exception handling on is: to catch exception only when and where you can do something with them (retry, get some relevant current data in the method...), or otherwise catch them
as high in the call hierarchy as possible (in your main loop or global exception handler - the higher the better, it means less exception handling for you to duplicate). And if you can't do anything with exception that would guarantee the consistency of your program state - don't catch it.
Ideally all classes should be resilient to failure - if they fail, they either fail and don't do anything afterwards or restore their state to normal. And the most ideal solution is if they rolled back any action's side effects in case of exceptions - transaction-like behaviour. But in real life it is a difficult goal to achieve.
Also, if you don't like similar try-catch constructs for logging everywhere in your code (they are important , but they aren't doing any real job - their presence isn't necessary for the understanding of the main workflow), you may try some of the Aspect Oriented Programming technologies.
Your question still missing many basic things like what kind of object "data" is, is it a string , class or any other type.
Well catching exception is never good for performance as long as your code handle all possible exceptions that might occur.
There can still be a scenario where exception is thrown.
I would suggest to check for field instead of directly calling field with that name, e,g,
bool active = data.HasField("active") ? data.GetField("active").Value<bool>() : false;
Also, In catch as common scenario better to pass exception object rather than e.Tostring()
something like :
Logger.LogError(e, this);
To conclude it really depends on application to applications or rather requirement to requirements.
In web Application, I usually create HttpModule for logging exception so that I dont have to write catch block everywhere in my code.
public class ExceptionModule : IHttpModule
{
public void Init(HttpApplication context)
{
context.Error += new EventHandler(OnError);
}
private void OnError(object sender, EventArgs e)
{
//write logging exception logic.
}
}
Should I catch exceptions in my method for "purely documenting" purposes, thus encapsulating the error-documentation inside the method itself, or is that responsibility of the caller?
Suppose I call numerous other methods in my EncryptPackage() method, including the framework ones, which potentially throw numerous exceptions. I wrap everything in using blocks, so no need to catch exceptions for cleanup (or I use try/finally for cleanup). Should I catch the exception anyway, and provide the details about the context of that method, or is it the responsibility of caller method?
Here is the case one:
[Serializable]
class TestClassException : Exception
{
public TestClassException() : base() { }
public TestClassException(string message) : base(message) { }
public TestClassException(string message, Exception innerException) : base(message, innerException) { }
}
class TestClass
{
public TestClass() { }
public void EncryptPackage()
{
try
{
DoSomething();
DoAnotherThing();
}
catch (Exception ex)
{
throw new TestClassException("Error occurred during package encryption", ex);
}
}
}
class ConsumerExample
{
public ConsumerExample() { }
public void DoSomeStuff()
{
TestClass testClass = new TestClass();
try
{
testClass.EncryptPackage();
}
catch (TestClassException ex)
{
System.Windows.Forms.MessageBox.Show(ex.ToString());
}
}
}
In this code, notice how the EncryptPackage() method catches all possible exceptions, just to "decorate the error text", with a "Error occurred during package encryption" text. EncryptPackage() here encapsulates the error-description logic.
And here is another technique:
class TestClass2
{
public TestClass2() { }
public void EncryptPackage()
{
DoSomething();
DoAnotherThing();
}
}
class ConsumerExample2
{
public ConsumerExample2() { }
public void DoSomeStuff()
{
TestClass testClass = new TestClass();
try
{
testClass.EncryptPackage();
}
catch (Exception ex)
{
System.Windows.Forms.MessageBox.Show("Error occurred during package encryption.\r\n\r\n" + ex.ToString());
}
}
}
In this example, EncryptPackage() does not catch anything, because the caller documents the error case anyway with "Error occurred during package encryption.\r\n\r\n" message.
Please note that this is a very simplified example, in real world there will be numerous hierarchical classes, and exceptions will be propagating through the long call stack, so which method of catching exceptions is preferred? Second approach seems "cleaner", because the exception is handled in a layer where some "actual handling" (e.g. displaying to user) is going to take place. Call stack information would be preserved in exception object, so technically it will be possible to find out where exactly the exception was thrown. But... that does not seem as "well-documenting" as the first approach, where each level of abstraction adds its own description to the error, preserving the previous exception in an innerException member. In this case, when the execution leaves the TestClass layer, it already contains detailed description of the error that happened within this class. So this feels to be the better encapsulation of error-handling logic.
Which one to use?
There is a chapter on this in Effective Java:
Higher layers should catch lower-level exceptions and, in their place,
throw exceptions that can be explained in terms of the higher-level
abstraction. This idiom is known as exception translation.
I prefer your second example, mainly because it can signicantly reduce the amount of error handling code you have to write, especially if you are writing custom exceptions - with the first example you could end up with a lot of custom exception classes which do not give much benefit (you already have the call stack to tell you where the exception came from).
You might think it is nice to have a more descriptive error message, but who benefits from this? The end-user? Should you even be displaying exception messages to your user (and what language are you going to use)? A lot of the time the user just needs to know that there has been an internal error, and they should give up (restart), or try again. Do you the developer benefit? You are probably going to end up examining the call stack anyway with the source code in front of you, so you don't really need a more descriptive message, you can see for yourself what the code is doing at that point.
This is not a hard and fast rule. Most of the time I only catch exceptions at the top level, where I log them and report an error to the user. If you are reporting the exception directly to the user, then often the original exception does not benefit from translation, e.g., if you try to open a non-existent file, then the System.IO.FileNotFoundException is descriptive enough so why translate it to something else? Do you really want to make the same judgement call ("I know better than the library author so I am going to translate their carefully crafted exceptions") for all of the gazillions of exceptions out there? I only catch exceptions lower down if I want to recover from them (generally not possible), or, very rarely, I want to translate them to a more descriptive exception.
In a layered architecture, it can make sense to translate exceptions between the layers, e.g., catch exceptions coming out of the data access layer to a form suitable for the application layer, and similarly between the application layer and the user interface, but I don't know if you are working on that type of system.
If you want to document your exceptions, you should use the exception tag in the xml documentation for the method. This can then be used to general help files from the documentation, e.g., using SandCastle.
As per #Sjoerd above, translate exceptions so they are in the same level of abstraction. In your case EncryptPackage should translate any lower-level exceptions itself, NOT the caller.
Say the lower-level exceptions were from a DB layer (say DBException). Would the caller expect to understand DBException? The answer is NO: the caller wants to encrpt a package, not a DBException. The lower-level exceptions should be chained INSIDE the higher-level exception for debugging purposes.
Finally, I know TestClassException is an example, but make sure the exception class describes the problem clearly: I, personally, don't like bland, generic exception classes (except to make a common base-class for other exceptions).
You should try/catch in few, easily distinguished situations:
any method that can be invoked "externally", such as your app's entry point, UI events, multi-threaded calls and others. Put some log output or message on each and every catch you have. This will prevent your app from crashing (for the most part) as well as provide you or the user with some feedback on how to fix the problem.
when you can really handle the exception. This means your app can, for example, opt for a secondary database or server URL, apply a different processing etc.
when you want to prevent something optional from ruining the main workflow, for example failing to delete your temp file shouldn't cause your process to fail.
there are probably some other places where you'll need a try/catch but these should be rare
Always combine error handling with a decent way of logging and/or messaging the user, don't let any exceptions info disappear because that's how you get apps and don't behave well for "no apparent reason" - at least the reason should be made apparent.
Also - don't use exceptions to control your workflow. There really shouldn't be any "throw"s unless there's absolutely no other way of doing something.
Could anyone create a short sample that breaks, unless the [ReliabilityContract(Consistency.WillNotCorruptState, Cer.Success)] is applied?
I just ran through this sample on MSDN and am unable to get it to break, even if I comment out the ReliabilityContract attribute. Finally seems to always get called.
using System;
using System.Runtime.CompilerServices;
using System.Runtime.ConstrainedExecution;
class Program {
static bool cerWorked;
static void Main( string[] args ) {
try {
cerWorked = true;
MyFn();
}
catch( OutOfMemoryException ) {
Console.WriteLine( cerWorked );
}
Console.ReadLine();
}
unsafe struct Big {
public fixed byte Bytes[int.MaxValue];
}
//results depends on the existance of this attribute
[ReliabilityContract( Consistency.WillNotCorruptState, Cer.Success )]
unsafe static void StackOverflow() {
Big big;
big.Bytes[ int.MaxValue - 1 ] = 1;
}
static void MyFn() {
RuntimeHelpers.PrepareConstrainedRegions();
try {
cerWorked = false;
}
finally {
StackOverflow();
}
}
}
When MyFn is jitted, it tries to create a ConstrainedRegion from the finally block.
In the case without the ReliabilityContract, no proper ConstrainedRegion could be formed, so a regular code is emitted. The stack overflow exception is thrown on the call to Stackoverflow (after the try block is executed).
In the case with the ReliabilityContract, a ConstrainedRegion could be formed and the stack requirements of methods in the finally block could be lifted into MyFn. The stack overflow exception is now thrown on the call to MyFn (before the try block is ever executed).
The primary driver for this functionality was to support SQL Servers stringent requirements for integrating the CLR into SQL Server 2005. Probably so that others could use and likely for legal reasons this deep integration was published as a hosting API but the technical requirements were SQL Servers. Remember that in SQL Server, MTBF is measured in months not hours and the process restarting because an unhandled exception happened is completely unacceptable.
This MSDN Magazine article is probably the best one that I've seen describing the technical requirements the constrained execution environment was built for.
The ReliabilityContract is used to decorate your methods to indicate how they operate in terms of potentially asynchronous exceptions (ThreadAbortException, OutOfMemoryException, StackOverflowException). A constrained execution region is defined as a catch or finally (or fault) section of a try block which is immediately preceded by a call to System.Runtime.CompilerServices.RuntimeServices.PrepareConstrainedRegions().
System.Runtime.CompilerServices.RuntimeServices.PrepareConstrainedRegions();
try
{
// this is not constrained
}
catch (Exception e)
{
// this IS a CER
}
finally
{
// this IS ALSO a CER
}
When a ReliabilityContract method is used from within a CER, there are 2 things that happen to it. The method will be pre-prepared by the JIT so that it won't invoke the JIT compiler the first time it's executed which could try to use memory itself and cause it's own exceptions. Also while inside of a CER the runtime promises not to throw a ThreadAbort exception and will wait to throw the exception until after the CER has completed.
So back to your question; I'm still trying to come up with a simple code sample that will directly answer your question. As you may have already guessed though, the simplest sample is going to require quite a lot of code given the asynchronous nature of the problem and will likely be SQLCLR code because that is the environment which will use CERs for the most benefit.
Are you running the MSDN sample under the debugger? I do not think it is possible for CER to function when you are executing within the debugger, as the debugger itself changes the nature of execution anyway.
If you build and run the app in optimized release mode, you should be able to see it fail.
While I don't have a concrete example for you, I think you're missing the point of have a try..finally block inside of the methods that guarantee success. The whole point of saying that the method will always succeed means that regards of what (exception) happens during execution, steps will be taken to ensure the data being accessed will be in a valid state when the method returns. Without the try..finally, you wouldn't be ensuring anything, and could mean that only half of the operations you wanted to happen, would happen. Thus, Cer.Success doesn't actually guarantee success, it only states that you as the developer are guaranteeing success.
Check out this page for an explanation of the differences between Success and MayFail states as it pertains to an Array.CopyTo method: http://weblogs.asp.net/justin_rogers/archive/2004/10/05/238275.aspx
CER attributes are means of documentation. They do influence how CLR will execute code in some situations, but I believe they (or lack of them) will never result in error in current versions of .NET.
They are mostly 'reserved for future use'.
Usually not calling Dispose indicates a possible error or sloppy code and may lead to some hard to find bugs. Ideally I would like to spot if Disposed was not called during unit tests.
One of the methods we used was to put Debug.Assert in the Finalizer
#if DEBUG
~MyClass()
{
Debug.Assert(false, “MyClass.Dispose() was not called”);
}
#endif
And we found ourselves clicking through assert message boxes but it didn’t work well with continuous integration builds that would ignore the popups.
If you log this somehow instead of using a Debug.Assert, and used dependency injection to specify your logger implementation, then you could use mock testing to catch this. So,
your class may take a logger instance in its constructor, or provide a default one, and then behave like this:
public MyClass : IDisposable
{
IEventLogger _eventLogger;
public MyClass() : this(EventLogger.CreateDefaultInstance())
{
}
public MyClass(IEventLogger eventLogger)
{
_eventLogger = eventLogger;
}
// IDisposable stuff...
#if DEBUG
~MyClass()
{
_eventLogger.LogError("MyClass.Dispose() was not called");
}
#endif
}
It is possible to write an fxCop rule to detect this issue.
Also, making sure that all uses of IDisposable are used inside a using{} block makes this much easier to deal with.
the rule I had checked for either manual calls to Dispose() or use of using{}
Manual calls to dispose are of course more difficult to detect in all situations, since there might be flow control or exceptions that may prevent the call from occurring.
You can use a Mock object framework (like RhinoMocks) to make sure IDisposable.Dispose() is called. If Dispose() were not called the framework will automatically fail the build.
I'm working on some code that uses a pattern in its business and data tiers that uses events to signal errors e.g.
resource = AllocateLotsOfMemory();
if (SomeCondition())
{
OnOddError(new OddErrorEventArgs(resource.StatusProperty));
resource.FreeLotsOfMemory();
return;
}
This looked superficially rather odd, especially as the code that calls this needs to hook into the events (there are four or five different ones!).
The developer tells me that this way they can refer to the properties of the allocated resource in the error handling code, and that responsibility for cleaning up after the error is kept by this tier.
Which makes some kind of sense.
The alternative might be something like
resource = AllocateLotsOfMemory();
if (SomeCondition())
{
BigObject temporary = resource.StatusProperty;
resource.FreeLotsOfMemory();
throw new OddException(temporary);
}
My questions are:
As this "BigObject" is freed when the exception object is released, do we need this pattern?
Has anyone else experience of this pattern? If so, what pitfalls did you find? What advantages are there?
Thanks!
It seems odd to me too. There are a few advantages - such as allowing multiple "handlers" but the semantics are significantly different to normal error handling. In particular, the fact that it doesn't automatically get propagated up the stack concerns me - unless the error handlers themselves throw an exception, the logic is going to keep going as if everything was still okay when it should probably be aborting the current operation.
Another way of thinking about this: suppose the method is meant to return a value, but you've detected an error early. What value do you return? Exceptions communicate the fact that there is no appropriate value to return...
This looks really odd to me, firstly IDisposable is your friend, use it.
If you are dealing with errors and exceptional situations you should be using exceptions, not events, as its much simpler to grasp, debug and code.
So it should be
using(var resource = AllocateLotsOfMemory())
{
if(something_bad_happened)
{
throw new SomeThingBadException();
}
}
If you think in terms of "Errors" and "Warnings", I've had lots of luck when reserving events for the "Warning" category and Exceptions for the "Errors" category.
The rationale here is that events are optional. No one is holding a gun to your head forcing you to handle them. That's probably okay for warnings, but when you have genuine errors you want to make sure they are taken a little more seriously. Exceptions must be handled, or they'll bubble up and create a nasty message for the user.
With regards to your Big Object question: you definitely don't be passing big objects around, but that doesn't mean you can't pass references to big objects around. There's a lot of power in the ability to do that.
As an addendum, there's nothing stopping from from raising an event in addition to the exception, but again: if you have a genuine error you want something to force the client developer to handle it.
Take a look at this post by Udi Dahan. Its an elegant approach for dispatching domain events. The previous poster is correct in saying that you should not be using an event mechanism to recover from fatal errors, but it is a very useful pattern for notification in loosely coupled systems:
public class DomainEventStorage<ActionType>
{
public List<ActionType> Actions
{
get
{
var k = string.Format("Domain.Event.DomainEvent.{0}.{1}",
GetType().Name,
GetType().GetGenericArguments()[0]);
if (Local.Data[k] == null)
Local.Data[k] = new List<ActionType>();
return (List<ActionType>) Local.Data[k];
}
}
public IDisposable Register(ActionType callback)
{
Actions.Add(callback);
return new DomainEventRegistrationRemover(() => Actions.Remove(callback)
);
}
}
public class DomainEvent<T1> : IDomainEvent where T1 : class
{
private readonly DomainEventStorage<Action<T1>> _impl = new DomainEventStorage<Action<T1>>();
internal List<Action<T1>> Actions { get { return _impl.Actions; } }
public IDisposable Register(Action<T1> callback)
{
return _impl.Register(callback);
}
public void Raise(T1 args)
{
foreach (var action in Actions)
{
action.Invoke(args);
}
}
}
And to consume:
var fail = false;
using(var ev = DomainErrors.SomethingHappened.Register(c => fail = true)
{
//Do something with your domain here
}
1) is it needed? no pattern is absolutely necessary
2) Windows Workflow Foundation does this with all the results from the Workflow Instances running inside the hosted runtime. Just remember that exceptions can happen when trying to raise that event, and you might want to do your cleanup code on a Dispose or a finally block depending on the situation to ensure it runs.
To be honest, events signaling errors strikes me as scary.
There's a disagreement between camps around returning status codes and throwing exceptions. To simplify (greatly) : The status code camp says that throwing exceptions places detecting and handling the error too far from the code causing the error. The exception throwing cap says that users forget to check status codes and exceptions enforce error handling.
Errors as events seems like the worst of both approaches. The error cleanup is completely separate from the code causing the error, and notification of error is completely voluntary. Ouch.
To me, if the method did not fulfill it's implicit or explicit contract (it didn't do what it was supposed to do), an exception is the apropriate response. Throwing the information you need in the exception seems reasonable in this case.
The first snippet should probably be
resource = AllocateLotsOfMemory();
if (SomeCondition())
{
try
{
OnOddError(new OddErrorEventArgs(resource.StatusProperty));
return;
}
finally
{
resource.FreeLotsOfMemory();
}
}
otherwise you won't free your resources when the event handler throws an exception.
As Mike Brown said, the second snippet also has a problem if resource.FreeLotsOfMemory() messes with the contents of resource.StatusProperty instead of setting it to null.
We have a base Error object and ErrorEvent that we use with the command pattern in our framework to handle non-critical errors (e.g. validation errors). Like exceptions, people can listen for the base ErrorEvent or a more specific ErrorEvent.
Also there's a significant difference between your two snippets.
if resource.FreeLotsOfMemory() clears out the StatusProperty value rather than just setting it to null, your temporary variable will be holding an invalid object when OddException is created and thrown.
The rule of thumb is that Exceptions should only be thrown in non-recoverable situations. I really wish C# supported a Throws clause that's the only thing I really miss from Java.
Another major problem with this approach are concurrency concerns.
With traditional error handling, locks will be released as control moves up the call stack to the error handler in a controlled manner. In this scheme, all locks will still be held when the event is invoked. Any blocking that occurs within the error handler (and you might expect some if there's logging) would be a potential source of deadlocks.