> Why not encapsulate the execution of any `SkunkClassificationRule` in a generic except block?
I've done that here in the latest change.  Now all predicates and actions are wrapped in a generic exception block so that they all exhibit the same behavior.  I think this is the correct thing to do.  However, I'm not sure how doing so forestalls your objections to the idiom - I would have expected this to compound it.

> you cannot know ahead of time what you're running
I can use this to argue in favor of my Exception handler.  While I know right now what each of the parameters are, their types and the ramifications of the use of their methods, I may not know in the future.  Will the Processor201[34] that is to replace the LegacyProcessor work the same way?  What about the case where an external user of Socorro has used Configman to replace the processor and it raises some exceptions of its own?  

>you are obligated to handle any error condition
I can use this to argue in my favor, too.   The TransformRule system has several modes of operation, but all are based on an ordered collection of predicate/action methods.  Right now this rule is used in set that is iterated until an action succeeds, whereas the rule processing stops.  The final rule in this ordered collection is the catch all - it defines what to do if none of the actions to succeed.  I'm "obligated" to catch exceptions raised during both the predicate and action phases to give that final rule the chance to execute. If an exception is allowed to jump out of the TransformRule process, the final catch all rule is not executed.  

I'm trying to create a system of predictable code execution paths from flexible components.  Exceptions are wildcards that allow execution to make leaps out of code blocks compounding the number of execution paths.  By catching Exceptions and folding their execution path into the same path as regular execution, I'm making a more predictable system.  The higher up the call chain that I allow an exception to jump, the less likely I am to be able to recover from those exceptions. 

In Processor201[34], all the transforms involved in making a raw crash into a processed crash will be encoded as in the form of rules.  These rules should be as small as possible, decoupled from each other and therefore independent.  I don't want an unexpected error in, for example, classification of a crash based on startup time, to stop a further rule (invocation of MDSW) from even being applied.