That’s terrible, and I would block that PR in a heartbeat, unless there was a very good reason for it (given context). I would instead prefer:
if foo isNone:
...
Exceptions are useful for bubbling up errors, they’re a massive code smell if you’re catching something thrown by local logic. Just like you shouldn’t catch IndexError right after indexing a list, you shouldn’t catch TypeError right after checking the length. If you need to check parameters, check them at the start of your function and return early.
Rejecting a PR shouldn’t be offensive, it should be a learning opportunity, both for the reviewer and the submitter. If I reject it, I’ll give a clear reason why, and suggestions on how to fix it. I’ll also engage in conversation if you’re not clear on why I made a given comment, as well as a defense for why your code should be accepted as-is (i.e. that context I’m talking about).
So please bother me with terrible, terrible code. I want to take time out of my day to help contributors learn, and I like pointing out areas where I learn something as well (like, “hey, this is really clever and also really easy to read, good job!”). I’m not always right, but I do have a lot of experience that I think others could benefit from. I know I was deeply appreciative of constructive criticism as a new dev, and I hope that’s true for the people I provide reviews for.
That’s terrible, and I would block that PR in a heartbeat, unless there was a very good reason for it (given context). I would instead prefer:
if foo is None: ...Exceptions are useful for bubbling up errors, they’re a massive code smell if you’re catching something thrown by local logic. Just like you shouldn’t catch
IndexErrorright after indexing a list, you shouldn’t catchTypeErrorright after checking the length. If you need to check parameters, check them at the start of your function and return early.Sir, I will make sure to never bother you with a PR and my terrible, terrible code ;)
Rejecting a PR shouldn’t be offensive, it should be a learning opportunity, both for the reviewer and the submitter. If I reject it, I’ll give a clear reason why, and suggestions on how to fix it. I’ll also engage in conversation if you’re not clear on why I made a given comment, as well as a defense for why your code should be accepted as-is (i.e. that context I’m talking about).
So please bother me with terrible, terrible code. I want to take time out of my day to help contributors learn, and I like pointing out areas where I learn something as well (like, “hey, this is really clever and also really easy to read, good job!”). I’m not always right, but I do have a lot of experience that I think others could benefit from. I know I was deeply appreciative of constructive criticism as a new dev, and I hope that’s true for the people I provide reviews for.