I think that regarding the possibility to catch defects, we are in a transitional state. By default, defects are catchable but this will change in the future. Personally, I never rely on the possibility to catch defects. That means that if I want to check for overflow, I don’t try to do the operation and catch the exception, but I do some inefficient tests to prevent the overflow. I find this ugly but, at least, there is a good reason to use a defect here: it is more efficient.
In other cases, doing a check before doing the operation is not a problem, for instance before dividing an integer or before indexing, because the check is easy to write and implied by the logic of the program. If the divisor may be zero or the index out of range without this being an error, it is normal to check these cases. As regards the conversion to enums, I don’t think that making them raise a catchable exception rather than a defect will be such a breaking change. The breaking change has already be done been when exceptions have been split in two categories using a different mechanism. Switching wouldn’t break a lot of thing. And, as I said, parseEnum already raises a ValueError not a RangeDefect.
