ça me dit surtout que le CLR a codé les exceptions avec les pieds pour aller au contre-courant de java, et comme c'est pourri chez eux, ils préconisent de les éviter.

je pourrais arguer que TryParse est débile niveau performances, vu qu'il va être quasiment toujours suivi d'un Parse et que donc, chaque nombre va se retrouver parsé deux fois. Par rapport à un lancer d'exception, ha ha ha.

PS: dans l'article ils proposent de tester:

public void methodThrowsException (String param) throws Exception {
if (param==null) {
throw new Exception("La valeur 'null' n'est pas acceptée");
}
// traitement
}

on peut faire encore mieux en passant pas de string à l'exception, parce que le type de l'objet contient déja l'info sur l'erreur.