My only concern with just letting it blow up is that this function is called within the context of handling an exception already. If it blows up by raising another exception, it'll obfuscate the original exception and might cause confusion. Strike that:  it'll definitely cause confusion, or at least it did when I was writing it. :smile: 

Couldn't figure out why, when I was throwing a custom exception, I not only wasn't handling it with the registered error-handler, it was somehow turning into an unhandled IllegalArgumentException. Burned some time trying to figure out why my initial throw+ code was throwing that exception instead. Turns out, in the predicate match, I had a typo that was causing a keyword to get passed to function instead of a variable.

I thought that returning false in those cases would at least cause the original exception to go unhandled, which gives a clear indication that the predicate isn't matching properly. I personally would prefer that while debugging over getting potentially any other kind of Exception raised from the predicate instead of the one I was expecting. And I'm not sure, but if an exception is raised within a catch clause, does it then get passed to the next catch clause for matching? If so, imagine if that raised exception was then erroneously swallowed up by a subsequent handler. Ugh.

That being said, I can see a legitimate case for both ways, so I'm happy to defer to your judgement.