Imagine an extensible business application built out of a dozen SoapBox add-ins. Some of these add-ins communicate with each other via IExecutableCommands and/or a message bus and each add-in has been modularly designed so that no two add-ins directly depend on one-another. Sounds great, doesn’t it? Life is good with SoapBox.
Now imagine what happens when one of those add-ins throws an unhandled exception(duh duh DUUUHHHHH). I don't have to imagine what happens because I have seen it happen... a lot. What happens is that the entire system - every plug-in and the core - crashed. With that in mind, let's imagin what we wish would happen.
I, at least, wish that one unhandled exception being thrown in one isolated add-in would only influence that one add-in. I mean I have designed the system to be modular and loosely coupled so why should an exception in one far corner of the application cause a completely un-related add-in to crash? It seems like there should be some way to change the design of the core to keep individual add-ins from crashing everything.
So my question is this: What can be done to limit the scope of unhandled exceptions in single add-ins so that they don’t crash the entire system like they do now? Can anyone think of a strategy for doing this? Is there a best practice or a pattern we can come-up with to at least partially solve this problem.
Now, some of you may be thinking, “Yeah, I’ve got an idea, test better and concentrate more on your exception handling”. I agree that is an important part of the solution and I don’t think it is the entire solution. First of all, I think that SoapBox is a great framework and if it can become even greater by providing a general way for dealing with some unhandled exceptions I don’t imagine anyone would object to that, right?
Secondly, add-ins are not always created and tested by a single developer or a single party. So when I get an add-in from someone else, or I release software that is meant to be extended by the people using it I sometimes have little or no control over the quality of every extension. That said, I don’t want someone who doesn’t know what they are doing to come along and ruin an otherwise good system with an add-in that throws lots and lots of unhandled exceptions. Put concisely, I am asking how can SoapBox be made more idiot proof at runtime?
It's a good question. There are some things you can do, but there are some built-in limitations too.
Add-ins are always extending existing add-ins or the host application. If you create an extension point, that means the module that created the extension point has the control. If you use an
However, once that add-in has control, it can always behave badly. First of all, it's all in one app-domain (this is a limitation of MEF). You can't just unload a misbehaving add-in. Secondly, it could spawn off other worker threads, and your exception handler won't be effective if one of those threads throws an exception.
I did some research into add-in security, and my conclusion was that you must trust the add-in author. This code will run in full-trust, just like all other applications that are actually installed locally on your computer. There's little you can do about the security aspect.
On the other hand, assuming you trust the add-in author, you should probably stick to normal exception handling rules, which is: fail early, and only catch exceptions you can handle.
answered 01 Apr '11, 22:51
Scott Whitlock ♦♦
Update: I recently stumbled upon a weird step-brother type of predecessor to MEF called The Managed Add-in Framework (MAF). MAF appears to have some shared goals with MEF but an overall different approach. One interesting component of MAF is an optional isolation boundary that is baked right into the relation between the add-in host and the add-in itself. Glenn Block himself seems to think MAF can be used with MEF to over-come the unhandled exception problem described above.
At first glance it looks like a fairly complex add-in model that requires a lot of work. I wonder how much of that is simple plumbing that can be abstracted or simplified via conventions.
More directly, my question now is: can SBC provide class that require MAF and can SBC make using MAF with MEF easy (or easier)?
If anyone has something to add, or knowledge/experience they'd like to share to help inform or guide me, it would be much appreciated. I am going to continue to explore the advantages that MAF can bring to SoapBox Core and will be sure to share any interesting findings with you all.
answered 11 Dec '11, 22:35