Well lets say the lib would create a set of exceptions which I want to demote to warnings or even ignore. Lets say there are 4 types of exceptions that I want to ignore or handle locally.
<snip>
Interesting example. I don't think I've ever ecountered code like that. A couple suggestions come to mind:
1) Design your error classes w/ hierarchies such that they allow a single catch() call to handle all cases.
2) Design your code so that you have a single method call which performs those related operations, so you only have 1 try/catch block.
In general, though, it is true that you cannot "turn off" exceptions the way you can turn off pear error. You can explicitly mark expected exceptions using try/catch. I don't think there's any reason why the try/catch method has to be more verbose (i.e. I think by re-evaluating design you'll get around the code redundancy issues you mention).
If you have an actual real-world example of this (in MDB,MDB2?) that might make the problem more tangibly severe. It still sounds like a hypothetical that wouldn't happen in practice -- or certainly wouldn't need to happen in practice.
Hans