Cet article est un complément à de nombreux traitements d'exceptions. Plus précisément, je laisserai le résultat de la vérification du modèle non introduit dans l'article.
Dans la fonction, vous pouvez écrire comme suit.
def method
puts "hoge"
a = 1 / 0
rescue ZeroDivisionError
puts $!
end
C'est une forme qui omet le début et la fin. Dans le cas d'une telle forme
a = 1 / 0
Cela va de soi qui provoquera une erreur. Mais si:
def method
#Traitement énorme 1
#Traitement susceptible de provoquer une erreur
#Traitement énorme 2
rescue StandardError
puts $!
end
Au fait, il est peu probable que la personne qui voit ce code puisse voir immédiatement le traitement susceptible de provoquer une erreur. Dans ce cas, je pense que vous devriez oser écrire le début et la fin.
def method
#Traitement énorme 1
begin
#Traitement susceptible de provoquer une erreur
rescue StandardError
puts $!
end
#Traitement énorme 2
end
De cette façon, vous pouvez voir où l'erreur est susceptible de se produire et vous n'avez pas à faire défiler beaucoup pour voir le sauvetage. En passant, si vous revenez avec sauvetage, l'énorme quantité de processus 2 ne sera pas traitée, donc si vous voulez vraiment qu'il soit traité, mettez-le en sécurité.
def method
#Traitement énorme 1
begin
#Traitement susceptible de provoquer une erreur
rescue StandardError
puts $!
return
ensure
#Traitement énorme 2(Traité même si le sauvetage est de retour)
end
end
S'il existe plusieurs processus susceptibles de provoquer une erreur, il est simple de les écrire tous ensemble à la fin de la fonction. L'écriture commencer, sauver, finir à chaque fois réduira la lisibilité. Tout va bien.
def method
#Traitement susceptible de provoquer diverses erreurs
#Autre traitement
rescue ZeroDivisionError, ArgumentError
puts $!
rescue StandardError
puts $!
puts $@
end
Au fait, si vous écrivez d'abord StandardError, ce type s'occupera de la plupart des erreurs. Commençons donc par la classe enfant.
Recommended Posts