Add retry_if_not_exception_type()

[henry0312]

Fixes #256

[jd]

Small typo

Pull request has been modified.

[asqui]

I think we can be clearer on the naming of this method to better communicate what it is doing.

Is this implementing the retry_if_exception_not_of_type which was propossed in the discussion of #137?

[henry0312]

Is this implementing the retry_if_exception_not_of_type which was propossed in the discussion of #137?

Yes, it it.
Though @jd approved this, would it be good to rename retry_except_exception_type to retry_if_exception_not_of_type?

[jd]

I'm fine with whatever.
We need to fix the CI not running issue to merge anything at this point 😢

[asqui]

I do think retry_if_exception_not_of_type would fit better amongst the existing family of related retry_* methods:

• retry_if_exception
• retry_if_exception_type
• retry_unless_exception_type -- might have been better named retry_if_not_exception_type retry_until_exception_type, but yolo.
• retry_if_result
• retry_if_not_result
• retry_if_exception_message
• retry_if_not_exception_message

In particular, I think it's important that the new method, whatever it's called, is clearly set apart from retry_unless_exception_type given the subtle but important differences between the two (as discussed, at length, in #137).

More generally, I'm slightly alarmed by the "I'm fine with whatever" remark. I worry that without careful consideration of usability, adoption of this library will be hampered in the future. (This is speaking as someone who has tried to bring tenacity in to an existing codebase which already has numerous disparate approaches to retry logic, and the complexity/usability concerns around tenacity have certainly been a barrier to adoption.)

[henry0312]

A relation between retry_if_exception_type() and retry_except_exception_type() is the same with one between retry_if_exception_message() and retry_if_not_exception_message(), since the implementation of retry_except_exception_type() is the essentially same with that of retry_if_not_exception_message().
(cf. https://github.com/jd/tenacity/blob/master/tenacity/retry.py#L125 and https://github.com/jd/tenacity/blob/master/tenacity/retry.py#L167)

Therefore, if I would rename, I think retry_if_not_exception_type is better than retry_if_exception_not_of_type, that follows the named rule of retry_if_not_exception_message.

---

For details,

• retry_if_exception_type(T)

T is included in conditons of retry.

• retry_except_exception_type(T)

T is excluded from conditions of retry.
In other words, T is not included in condtions of retry.

• retry_if_exception_message(A)

A is included in conditons of retry.

• retry_if_not_exception_message(A)

A is excluded from conditions of retry.
This means that T is not included in condtions of retry.

By the way,

• retry_unless_exception_type(T)

Retry until T is raised.
(T is expected to be raised to stop retry)

---

I'm not good at English and I'm sorry for my bad English.

[asqui]

@henry0312 Thanks for taking the time to look at this in such detail.

I agree that retry_if_not_exception_type fits better with the existing naming conventions.

P.S. Don't apologise, your english is great! (I have no reason to believe you're not a native speaker!)

Pull request has been modified.

[henry0312]

@jd @asqui I just renamed retry_except_exception_type to retry_if_not_exception_type

Pull request has been modified.

[henry0312]

@jd I just fixed tests!

[henry0312]

@jd Thank you for reviewing and merging.
Do you have a plan for a new release?

[william-silversmith]

Likewise! Thanks so much jd and all that contributed! I would start using this feature once the next release is out.