|
Bienvenue
visiteur !
|
Désactiver
la neige
Statistiques
Liste des
membres
Contact
Mentions légales
245 connectés actuellement
30835016 visiteurs
depuis l'ouverture
2283 visiteurs
aujourd'hui
Partenaires
Tous nos partenaires
Devenir
partenaire
|
|
◂
| Les exceptions en Ruby
Ici, vous découvrirez les procédés généraux concernant la gestion d'une exception en Ruby. | Ecrit par Denzel Lockheart$ le 30/01/2010 |
▸
|
❤ 0 Ici, je vous présenterai un outil utile pour gérer les erreurs en Ruby : les exceptions. Vous devez savoir que tout doit se
mettre dans un bloc d'instructions entre begin et end.
1) Gestion générale d'une exception
De manière générale, voici la démarche à suivre :
1
2
3
4
5
| begin
#Instructions d'erreur
rescue <exception>
#Instructions de gestion de l'exception
end |
Pour donner l'exemple le plus simple, on va effectuer une division par zéro.
1
2
3
4
5
| begin
1/0
rescue ZeroDivisionError
puts "Erreur : Division par zéro impossible !"
end |
2) Instruction effectuée après une exception
Pour cela, on utilise le mot-clé ensure. C'est à peu près la même chose.
1
2
3
4
5
6
7
| begin
#Instructions d'erreur
rescue <exception>
#Instructions de gestion de l'exception
ensure
#Instructions après la gestion de l'exception
end |
En reprenant notre exemple, on aurait :
1
2
3
4
5
6
7
| begin
1/0
rescue ZeroDivisionError
puts "Erreur : Division par zéro impossible !"
ensure
puts "Et voilà ! On a géré l'exception !"
end |
3) Gérer l'exception avec une instruction de secours
Il est possible de rattraper le coup d'une exception grâce au mot-clé retry. Attention, car cette instruction s'exécute comme
une boucle infinie, donc initialisation obligatoire !
1
2
3
4
5
6
7
| begin
#Instructions d'erreur
rescue <exception>
# Instructions de gestion de l'exception
# Nouvelles instructions sans erreur
retry # Pour réessayer
end |
On va supposer que le dénominateur est cette fois une variable à initialiser.
1
2
3
4
5
6
7
8
9
| a=0
begin
5/a
rescue ZeroDivisionError
puts "Erreur : Division par zéro impossible !"
a=2
retry
end
puts "Ouf ! On a réussi !" |
A partir de là, vous saurez comment gérer une exception en Ruby de manière générale.
|
|
| Webmasters anonymes | Normalement en RGSS, vous n'aurez pas cette exception à gérer, mais ça pourra servir pour gérer un système de fichiers externes sur le même schéma.
|
http://www.inlibroveritas.net/lire/oeuvre36096.html |
Lufia -
posté le 30/01/2010 à 22:39:49 (5792 messages postés)
| Un Oniromancien. PVs 1, Attaque 0, Défense 0. | J'ai accepté ce tuto mais je trouve qu'il manque un peu de précision à certains endroits.
Le mot clé rescue utilisé sans rien après interceptera toutes les erreurs de type StandardError, soit une bonne partie des erreurs que l'on peut provoquer avec RM.
rescue ZeroDivisionError ne permettra de gérer que les erreurs de division par zéro.
ensure permet de s'assurer que du code dans un bloc sera toujours exécuté, qu'il y ait un erreur avant ou pas.
On peut utiliser rescue et ensure dans des définitions de méthode.
|
Une signature ? Pour quoi faire ? |
Åvygeil -
posté le 31/01/2010 à 00:57:04 (2502 messages postés)
| | C'est moi ou il manque un côté de la pièce ?
|
|
| Webmasters anonymes | Effectivement, il manque certaines exceptions à gérer en RGSS mais je ne les ai pas évoquées car j'ai voulu faire beaucoup plus général avec une seule exception. Mais il est évident que ça peut totalement différent d'une exception à l'autre !
Par exemple pour RGSSError, ce sera totalement différent !
De toute façon, s'il fallait que je montre comment gérer toutes les exceptions, il y a aurait pour des pages de codes tellement le sujet est complet !
|
http://www.inlibroveritas.net/lire/oeuvre36096.html |
Åvygeil -
posté le 31/01/2010 à 10:42:33 (2502 messages postés)
| | Non mais attends, les exceptions, le principe c'est pas que de les intercepter.
Le principe c'est aussi d'en lever. L'autre côté de la pièce quoi.
|
|
| Webmasters anonymes | Euh... J'ai pas trop compris, là !
J'avais pourtant utilisé toutes les clauses correctement et j'ai même testé avec la console Ruby intéractive fxri. Je ne comprends toujours pas, tu pourrais juste mettre un exemple concret ?
En même temps, je pourrais toujours demander à Lufia pour modifier et améliorer le tuto !
|
http://www.inlibroveritas.net/lire/oeuvre36096.html |
Åvygeil -
posté le 31/01/2010 à 12:04:07 (2502 messages postés)
| |
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
|
class MonException < Exception
def to_s
"Mon exception est levée !"
end
end
def raise_monexception
raise MonException
end
begin
raise_monexception
rescue MonException => ex
puts ex
end
|
L'utilisation de "raise" pour lever une exception quoi...
Je vois pas ce qui était *si dure* à comprendre dans ce que j'ai dit.
Franchement... franchement....
|
Lufia -
posté le 31/01/2010 à 12:53:59 (5792 messages postés)
| Un Oniromancien. PVs 1, Attaque 0, Défense 0. | "l'autre côté de la pièce", j'avais pas compris non plus. Sûrement parce que je compte en euros.
Tiens, Avy, vu que tu vas sûrement lire ce message, je voulais savoir, raise ça va forcément s'utiliser dans une condition, non ?
Ah, et dans la doc Ruby, j'ai vu ça sur rescue :
1
2
3
4
5
6
| def file_reverser(file)
File.open(file) {|fh| puts fh.readlines.reverse }
rescue Errno::ENOENT
log "Tried to open non-existent file #{file}"
raise
end |
Utiliser raise comme ça, ça va faire tourner le programme en boucle, non ?
Ah, et j'aurais écrit ça :
1
2
3
4
5
| begin
raise_monexception
rescue => ex
puts ex.to_s if ex == MonException # Pas sûre de l'opérateur
end |
C'pareil ?
|
Une signature ? Pour quoi faire ? |
Åvygeil -
posté le 31/01/2010 à 13:39:36 (2502 messages postés)
| | Point 1 : Non ça ne va pas faire tourner le programme en boucle.
Ce bout de code fait que si on lève une exception, on envoie u message dans le log, et on finit par planter.
L'exception levée par le "raise" dans "file_reverser" n'est pas interceptée parce qu'il est dans le rescue, pas le bloc principal.
Point 2 : Non ce n'est pas pareil.
"rescue" tout seul marche si l'exception ex est une StandardError si je me rappelle bien. Ce qui n'est pas le cas pour MonException.
Et "ex == MonException" n'a pas de sens, vu que "ex" est un instance de "MonException", pas la classe elle-même.
Et tester le type de l'exception c'est très mauvais, plutôt faire :
1
2
3
4
5
6
7
8
9
|
begin
# du code...
rescue MonException1 => ex
puts ex
rescue MonException2 => ex
puts ex
end
|
|
|
| Webmasters anonymes | Ben merci du conseil ! Je pensais pas qu'il fallait approfondir jusqu' ici !
Je vais renvoyer le tuto avec les nouveaux éléments car sinon, je vais encore me taper la honte !
Sinon, Lufia peut supprimer le tuto en attendant une nouvelle version si ça dérange en attendant.
|
http://www.inlibroveritas.net/lire/oeuvre36096.html |
Zeus81 -
posté le 31/01/2010 à 19:49:07 (11071 messages postés)
| | Quel succès n'empêche ces tutos, ça n'intéresse que ceux qui savent déjà programmer. :'-)
Et j'ai du mal à comprendre en quoi un débutant aurait besoin des exceptions.
J'sais pas, je préfère vérifier si le dénominateur est égal à zéro plutôt que de faire une exception, c'est moins lourd.
Et pour ne pas poster inutilement, je rajouterai que pour récupérer l'erreur on peut utiliser $! plutôt que de mettre => ex
qu'on peut récupérer le message d'erreur avec $!.message
et la ligne avec $!.backtrace
|
|
| Webmasters anonymes | Je pense que vous n'avez pas compris que c'est juste pour le principe. J'aurais pu être beaucoup plus général, mais je vais de toute façon changer le contenu de ce tuto.
|
http://www.inlibroveritas.net/lire/oeuvre36096.html |
|
|
|
Chat
