>     it has ever been so and is very useful.  Personally I would prefer the proceed ability if exceptions to be changeable depending in circumstance.

It already is.  Just implement isResumable  ^true temporarily (and in
the meantime reconsider the design of the app's use of a non-resumable
exception for that case).

> eg initialise a canPeoceed inst car to the class default but allow knowledgeable clients to alter the status quo.  Often exception designers err on making errors not proceedable.  For example accessing a directory's contents.  If implementing find (1) it's useful to be able to proceed with an empty collection, to skip directories one doesn't have the permissions to read.

Yes, I know what you are saying, but I'm talking about non-resumable
Errors.  There are cases when the code following the signal absolutely
should not run; e.g. if the user mistakenly clicked Proceed and there
were "repercussions" for resuming the code there.

Actually, this issue is not serious for the release like the step over
Warning and the step through image lockup issue are.  If we cannot get
those fixed in another week, we may wish to rollback the offending
change(s) so we can release, re-open development for trunk, and mount
another attack on those changes.