It's one of those areas where the language is an inconsistently designed mess.
Consistent language design would mean that END would always have the same effect, and that the BREAK of a WHILE should have the same effect as a caught error in a CATCH. Neither is the case in T-SQL.
This is the situation we have (at least in sqls 2008 R2 it was - I haven't checked since then, and I'm sure it isn't documented):
the END of a CATCH block sets @@rowcount to 0
the END of a TRY block sets @@rowcount to 0
the END of an ELSE block doesn't change @@rowcount
the END of an IF block doesn't change @@rowcount
the END of a WHILE block sets @@rowcount to 0 (hence you can't tell what the CONTINUE of a while block does to @@rowcount)
the BREAK of a WHILE block leaves @@rowcount unchanged
the END of a try block sets @@rowcount to 0 even if the catch block is entered (so error in try is not like break in while).