Je ne vois vraiment pas une utilisation sane pour ces. Il y a déjà sauvetage code> et élever code>, alors pourquoi le besoin de lancer code> et attrape code>? Il semble qu'ils soient supposés être utilisés pour sauter de la nichonnée profonde, mais cela sent un aller à moi. Y a-t-il des exemples de bonne utilisation propre pour ceux-ci? P>
4 Réponses :
C'est fondamentalement un goto, et légèrement plus semblable à un appel / cc, sauf que le flux de contrôle est câblé implicitement par nom au lieu d'un paramètre explicitement en tant que paramètre. La différence entre lancer / attraper et lever / sauvetage est que le premier est destiné à être utilisé pour le flux de contrôle au lieu de situations exceptionnelles, et il ne perd pas de temps à mettre en place une trace de pile. P>
SINATRA utilise des codes d'erreur HTTP, où un gestionnaire peut utiliser un contrôle de cèdre à la bibliothèque Sinatra de manière structurée. D'autres sortes de cadres HTTP utilisent des exceptions ou en renvoyant une classe de réponse différente, mais cela permet à SINATRA (par exemple) essayer un autre gestionnaire de demande après l'avoir attrapé. P>
Une grande différence est que vous pouvez mais ce n'est pas terriblement significatif. Mais vous ne pouvez pas faire: p> lancer code> tout, pas seulement des choses qui sont dérivées de StandardError code>, contrairement à code>. Quelque chose d'idiot comme celui-ci est légal, par exemple: p>
L'exemple est légal avec un sauvetage / relance aussi. Cela dit simplement "classe ou module requis pour la clause de secours".
En outre, il me dise que vous ne pouvez attraper / jeter un symbole.
@JleeDev »Quelle version de Ruby utilisez-vous? [EDIT: Oups, j'ai mal interprété ce que vous avez dit. J'ai mal dactylographié cette dernière phrase, va réparer.]
Dans Ruby 1.8.6. Lancer / élever des objets du mauvais type: codépad.org/ofyeardw
@JleeDev: dans 1.9 cela fonctionne, donc cela l'explique. Intéressant!
Je pense que le lancer doit également voir un bloc de «capture» actif afin de travailler, tout comme la soulever doit voir un «sauvetage» actif. S'il n'y a pas de bloc de capture correspondant, il y aurait NameError.
La différence entre les deux est que vous ne pouvez que "élever" des exceptions mais que vous pouvez "jeter" n'importe quoi (1.9). Outre cela, ils devraient être interchangeables, c'est-à-dire qu'il devrait être possible de réécrire un avec un autre, tout comme l'exemple donné par @ John-Feminella. P>
Ils peuvent être vraiment utiles pour simplifier les DSL pour les utilisateurs finaux en passant au contrôle de la DSL sans avoir besoin de cas complexe / si des instructions fortes> J'ai une application Ruby qui permet aux utilisateurs de s'étendre il via une DSL interne. Certaines des fonctions de la DSL doivent renvoyer le contrôle à des parties spécifiques de ma demande. Prenons un exemple simple. Supposons que l'utilisateur développe une simple extension concernant les dates p> le Plutôt que de continuer à exécuter la DSL, à une condition, nous voulons qu'il quitte et contrôle de la main à mon application. Maintenant, vous pouvez demander à l'utilisateur d'utiliser beaucoup de relevés si des déclarations et que les DSL se terminent naturellement, mais cela obscurcit simplement ce que la logique essaie de dire. P> lancer est vraiment un goto qui est «considéré comme dangereux» mais Bon sang, parfois ils sont la meilleure solution. p> p> ne code> déclenche un coup qui passe le contrôle de l'instruction Exec et de retour à Moi. P>