They say that "code should be owned by the team", so a review is not so much a personal attack on an individual coder, but a quality step to ensure things are understandable by the rest of the team. I'd say most places I've worked, this is understood and accepted.
However, I did interview a guy who was so against the idea of reviewing other people's code that we rejected him as a candidate! (that is - not of having his code reviewed, but doing reviews... it was weird).
That made me think a little about the problem with how some people approach reviews. I'd say a better way of doing code reviews then is to remember the first line on my answer, and build on that. To do this is quite simple: a code review stops being the perceived "someone checks out my code and tells me what I've done wrong" and becomes an opportunity for the coder to tell someone else what their code does, how it does it, and what changes they've made.
In this case, the coder will end up reviewing their own code, with an extra pair of eyes to help spot the bit they might miss. It's also a chance for the coder to explain why he did things a certain way. Such an approach is just as effective (if not more so as you have a good exchange of communication) and considerably more friendly. I don't think it would take more time considering the review should be quicker as the original coder can explain the changes directly. People should also understand the need for such a review as they are "handing over" the knowledge to another team member who might be required to maintain the code in the future.
You can enhance this by having the 'reviewer' come prepared with the original requirements for the change, and tick them off as their solution is detailed, so it would feel even less like a code review.
