Of course, I'm happy and grateful if colleagues point out bugs in my PR before I merge it into master (and this saved me from embarrassment or causing troubles several times).
That said I don't expect colleagues to look for bugs or to catch bugs.
Why?
Catching bugs just by looking at the code takes a lot of time and focus. There's a class of bugs that is easier to spot if you didn't write the code, even if you just look at it. But really looking for bugs needs way too much effort and takes too much time for code reviews.
I think there are a lot of techniques and practices to catch bugs, to me it's dangerous skipping on those because you assign responsibility to catch bugs to code reviews.
While there are several effective techniques and practices to catch bugs, there aren't that many opportunities to learn from your colleagues, regardless if you learn from the way they see your code or you learn from the way you read/see their code.
I want the main focus to be about checking if you could work with this code (or the coupling it introduces) in the future if somebody catches a bug, that's awesome but it's just a bonus/side effect.
In the end, it depends on the team and the product/requirements. That's what has worked for me in the past. But that doesn't mean that I don't believe that your approach couldn't be the right one for me in some context.
In code review when looking for bugs, you just need to think about whether the right conditions are tested.
I think this is something that's working well in code reviews because of the different view when you haven't written the code yourself.
Also if you try to understand what the code does, often possible bugs become apparent almost automatically.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Of course, I'm happy and grateful if colleagues point out bugs in my PR before I merge it into master (and this saved me from embarrassment or causing troubles several times).
That said I don't expect colleagues to look for bugs or to catch bugs.
Why?
In the end, it depends on the team and the product/requirements. That's what has worked for me in the past. But that doesn't mean that I don't believe that your approach couldn't be the right one for me in some context.
In code review when looking for bugs, you just need to think about whether the right conditions are tested.
I think this is something that's working well in code reviews because of the different view when you haven't written the code yourself.
Also if you try to understand what the code does, often possible bugs become apparent almost automatically.