C'est pas une bonne pratique de lancer des exceptions à tout va.
En théorie déjà parce qu'une exception dénote un cas exceptionnel, qui n'est pas censé arriver (s'il arrive alors c'est que ton appli a PLANTE, pas juste qu'une méthode ne peut pas continuer pour une raison ou une autre), si bien que certains langages ou libs (comme celle de Objective-C il me semble) ne te garantissent même pas que le programme pourra continuer proprement après une exception (sans leak ou autre).
Et en pratique, c'est lent et ça cause plein de problèmes, dès que tu fais du RMI, dès que tu fais par exemple interagir des EJB avec des SpringBean, et j'en passe. Je ne compte pas les fois où on est revenu en arrière en remplaçant les possibles exceptions par une énumération comme valeur de retour.
Mais évidemment si tu es cantonné dans ton monde Java tu ne peux pas comprendre, car c'est un langage qui du fait qu'il est mal foutu force à utiliser des exceptions là où il ne faudrait pas. L'absence de paramètres out par exemple qui permettrait de faire:
[NSString stringWithContentsOfURL:@"http://caca.com" error:&errorDetailsIfNeeded]
Même le fait qu'on ne puisse pas se connecter à un serveur n'est pas forcément un cas exceptionnel, c'est quelque chose qui peut arriver, à gérer. Si par contre l'appli ne peut pas fonctionner du tout sans connexion, alors là seulement lancer une exception en cas d'échec serait justifié.