[Rivet] Unsuitable error checking

[Frank Siegert]

> We'll need to discuss this in Glasgow. That's just not the right way to deal
> with combinations. Tevatron Run 1 could just as well claim to need generator
> runs with showering and hadronization turned off.

We are talking about a statistically highly limited analysis here,
where we have to do a combination of different decay channels to have
any meaningful data comparison at all. This is early Higgs measurement
days, so this will hopefully be better in a few years, but it's
substantially different from turning hadronisation off or correcting
back to the (QCD) parton level in my opinion. Note that the individual
analysis also exists (ATLAS_2014_I1306615 H->yy) but as I said isn't
as useful.
We can discuss in Glasgow, whether there is any better way.

>> causing somebody to accidently waste lots of CPUh
>
> That's really not our problem. The current situation would have wasted one
> day of _my_ time had I not noticed. I don't see why we need to favour one
> over the other.

I'm not arguing for keeping the abort, and I would also lean towards
vetoEvent. But I don't quite understand the use case of running all
kinds of analyses (for different physics processes) in the same run:
this won't go along with the idea of having background-subtracted
particle level measurements. So it must be an uncommon debugging use
case?

I also don't understand how it would waste one *day* of anybody's time
to see that a job crashes and then submit it with stable Higgs or the
analysis disabled.

Cheers,
Frank