I was thinking that the model of event-driven programming is that the code that raises the event should not depend upon the successful execution of any of the handlers of the event (e.g. fire and forget), and therefore the exception should not be propagated back.
But I think Stewart's argument probably trumps this concern. It would be worse to hide serious problems, so maybe it should always rethrow. I still wonder if "throw e" shouldn't be modified to "throw" (there is a slight difference in the way that .NET reports the stack trace). j _____ From: Stewart Bright [mailto:[EMAIL PROTECTED] Sent: Thursday, July 12, 2007 10:52 AM To: 'Jonathan Resnick'; [email protected] Subject: RE: [clearcanvas_dev] EventsHelper I think the reason it re-throws is because not doing so can potentially hide a serious problem from the user. Unless we decide that the EventsHelper only gets used to fire 'safe' events. -Stewart From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jonathan Resnick Sent: July 12, 2007 10:45 AM To: [email protected] Subject: [clearcanvas_dev] EventsHelper I'm wondering why the EventsHelper class rethrows the exception? Having it rethrow happens to be quite useful for debugging, but conceptually I don't think it actually makes sense, and therefore it seems to me that in production code it should not rethrow the exception. The catch block currently looks like this: catch (Exception e) { Platform.Log(e, LogLevel.Error); throw e; } I think it should look like this: catch (Exception e) { Platform.Log(e, LogLevel.Error); #if DEBUG throw; #endif } Any thoughts? (Or, does anyone remember why the code is the way it is?) j __________ NOD32 2395 (20070712) Information __________ This message was checked by NOD32 antivirus system. http://www.eset.com
_______________________________________________ dev mailing list [email protected] http://clearcanvas.ca/mailman/listinfo/dev_clearcanvas.ca
