Exceptions vs valeurs de retour, ou quand ne pas lever Exceptions vs return values, or when not to raise

Une exception est pour l'anormal — pas pour un cas qu'on attendait.An exception is for the abnormal — not for a case you expected.

On a appris à lever et à structurer les erreurs ; ce dernier numéro demande l'inverse : quand NE PAS lever. Une exception déclare un événement exceptionnel — un état impossible, une invariant brisée. Mais beaucoup de cas qu'on traite par raise ne sont pas exceptionnels du tout : une clé absente, une fin de fichier, un utilisateur introuvable, une saisie invalide. Ce sont des issues attendues, prévues, fréquentes. Les lever coûte une stack trace construite puis jetée, et détourne le flux pour une situation normale. Souvent, une valeur de retour — un nil, un objet Result — dit mieux et moins cher ce que l'exception criait.We learned to raise and to structure errors; this last issue asks the opposite: when NOT to raise. An exception declares an exceptional event — an impossible state, a broken invariant. But many cases handled by raise aren't exceptional at all: a missing key, an end of file, a user not found, invalid input. These are expected, anticipated, frequent outcomes. Raising them costs a stack trace built then discarded, and diverts the flow for a normal situation. Often, a return value — a nil, a Result object — says better and cheaper what the exception shouted.

# « introuvable » est-il une ERREUR, ou un résultat ATTENDU ?

# version exception : lève pour une absence pourtant banale
def find_user(id)
  users[id] || raise(NotFound, "user #{id}")   # construit une stack trace…
end
find_user(99) rescue nil                        # … qu'on jette aussitôt

# version valeur : l'absence est un nil, dit sans drame
def find_user(id) = users[id]   # => nil si absent
user = find_user(99)
greet(user) if user             # le cas « absent » fait partie du flux normal

L'exception comme flux coûte une stack trace — et cache le flux.The exception as flow costs a stack trace — and hides the flow.

Détourner les exceptions vers le contrôle de flux a deux coûts. Le premier, mesurable : lever construit une trace de pile — Ruby capture où on est dans tout l'appel — puis on la jette aussitôt. Dans une boucle chaude, sur un cas fréquent, c'est un ordre de grandeur plus lent qu'un simple if. Le second, plus insidieux : le flux devient illisible. Un next ou un return cachés dans un rescue déguisent du contrôle ordinaire en gestion d'erreur ; le lecteur doit reconstituer que « invalide » n'était pas une panne mais une branche attendue. Rendre une valeur garde le chemin normal droit, visible, et gratuit.Diverting exceptions into control flow has two costs. The first, measurable: raising builds a stack trace — Ruby captures where you are in the whole call — then you discard it at once. In a hot loop, on a frequent case, it's an order of magnitude slower than a plain if. The second, more insidious: the flow becomes unreadable. A next or return hidden in a rescue disguises ordinary control as error handling; the reader must reconstruct that 'invalid' wasn't a failure but an expected branch. Returning a value keeps the normal path straight, visible, and free.

# Lever pour piloter le flux normal : coûteux ET illisible
def import(rows)
  rows.each do |row|
    begin
      save(row)
    rescue InvalidRow            # « invalide » est ATTENDU sur un import…
      next                       # … mais on s'en sert comme d'un « continue »
    end
  end
end

# à chaque ligne invalide : une exception levée, une stack trace construite,
# le flux dévié — pour un cas parfaitement prévu. Lent en boucle chaude,
# et le « next » caché dans un rescue brouille la lecture.

Sur un import, des lignes invalides sont attendues — c'est la norme, pas l'anomalie. Les traiter par raise/rescue construit une trace de pile par ligne fautive, pour la jeter aussitôt, et planque le « continue » dans un rescue. On paie un mécanisme conçu pour l'exceptionnel à chaque tour d'une boucle ordinaire.On an import, invalid rows are expected — the norm, not the anomaly. Handling them with raise/rescue builds a stack trace per faulty row, only to discard it, and hides the "continue" in a rescue. You pay a mechanism designed for the exceptional on every turn of an ordinary loop.

Les outils du « sans exception » : fetch, nil, Result, catch.The "no exception" toolkit: fetch, nil, Result, catch.

Ruby outille richement le « cas attendu sans lever ». fetch porte la nuance en un seul nom : fetch(k) lève si l'absence est anormale, fetch(k, défaut) ou fetch(k){…} rend une valeur si elle est prévue — tu choisis le sens. Beaucoup de méthodes du cœur offrent une variante sans exception, comme Integer(str, exception: false). Pour un échec qui doit voyager avec ses détails, un objet Result encapsule succès ou erreur en une donnée que l'appelant inspecte. Et catch/throw, souvent oublié, offre un vrai saut de contrôle — un break profond — sans détourner le système d'exception. Quatre outils pour garder l'exception à sa place : l'exceptionnel.Ruby richly tools the 'expected case without raising'. fetch carries the nuance in one name: fetch(k) raises if absence is abnormal, fetch(k, default) or fetch(k){…} returns a value if it's expected — you choose the meaning. Many core methods offer an exception-free variant, like Integer(str, exception: false). For a failure that must travel with its details, a Result object wraps success or error into data the caller inspects. And catch/throw, often forgotten, offers a real control jump — a deep break — without hijacking the exception system. Four tools to keep the exception in its place: the exceptional.

# 1. fetch : exception pour l'inattendu, défaut pour l'attendu
h = { a: 1 }
h[:b]                  # => nil          accès silencieux
h.fetch(:b)            # KeyError        « ça DOIT être là » → exceptionnel
h.fetch(:b, 0)         # => 0            « ça peut manquer » → défaut, sans lever
h.fetch(:b) { compute }# => défaut paresseux

# 2. la variante sans exception, quand elle existe
Integer("oops")                    # ArgumentError
Integer("oops", exception: false)  # => nil   l'échec attendu rendu en valeur

# 3. un objet Result : porter le succès OU l'échec comme une donnée
Result = Data.define(:ok, :value, :error)

def parse_amount(str)
  Result.new(ok: true, value: Integer(str), error: nil)
rescue ArgumentError => e
  Result.new(ok: false, value: nil, error: e.message)
end

r = parse_amount(input)
r.ok ? save(r.value) : show(r.error)   # les deux issues, dans le flux

# 4. catch/throw : un SAUT de contrôle non-erreur (pas une exception)
found = catch(:hit) do
  grid.each { |row| row.each { |x| throw(:hit, x) if x.negative? } }
  nil                                  # rien trouvé
end

Note le pont avec le Vol 1 : nil est un objet (pas un null), donc une issue « absente » rendue comme valeur reste un objet à qui l'on parle — avec &., to_a, un défaut via ||. Rendre une valeur n'affaiblit pas le typage du canard (Vol 3) : ça le garde, là où l'exception l'aurait court-circuité.Note the bridge to Vol 1: nil is an object (not a null), so an "absent" outcome returned as a value stays an object you talk to — with &., to_a, a default via ||. Returning a value doesn't weaken duck typing (Vol 3): it keeps it, where the exception would have short-circuited it.

Lever puis rattraper aussitôt : un if déguisé en panne.Raise then rescue at once: an if disguised as a failure.

Le contre-exemple du numéro est un motif si courant qu'on ne le voit plus : fetch sans défaut qui lève, immédiatement enveloppé d'un rescue qui fournit la valeur de repli. L'exception naît et meurt dans la même méthode, à deux lignes d'écart — elle ne signale rien, elle pilote le flux. Et ce flux était une banalité : une clé de config absente, repliée sur un défaut. Le même fetch sait faire ça sans lever : avec un défaut ou un bloc, il rend le repli directement. On garde la version qui lève uniquement quand l'absence est vraiment anormale — quand la clé DOIT exister. Le réflexe : si tu rattrapes une exception au même endroit où tu la lèves, c'est qu'elle n'aurait pas dû être levée.The issue's counter-example is a pattern so common it's invisible: fetch without a default that raises, immediately wrapped in a rescue providing the fallback. The exception is born and dies in the same method, two lines apart — it signals nothing, it drives the flow. And that flow was trivial: a missing config key, falling back to a default. The same fetch does this without raising: with a default or a block, it returns the fallback directly. You keep the raising version only when the absence is truly abnormal — when the key MUST exist. The reflex: if you rescue an exception in the same place you raise it, it shouldn't have been raised.

# Le piège : lever pour une clé absente, puis la rattraper comme un défaut
def setting(key)
  CONFIG.fetch(key)          # lève KeyError si la clé manque…
rescue KeyError
  DEFAULTS[key]              # … qu'on rattrape AUSSITÔT : l'erreur EST le flux
end

setting(:timeout)
# à chaque clé absente — cas banal d'une config — une exception est levée,
# une stack trace construite puis jetée. On a écrit un « if » en trois lignes
# coûteuses, et déguisé une valeur par défaut en gestion d'erreur.

# Le défaut, rendu comme valeur : ni exception ni backtrace
def setting(key)
  CONFIG.fetch(key) { DEFAULTS[key] }   # le bloc fournit le repli, sans lever
end

setting(:timeout)              # => la valeur, ou le défaut — flux droit

# et si « absente » devait rester une vraie erreur, on garde fetch SANS bloc :
def setting!(key) = CONFIG.fetch(key)   # là, KeyError est justifié : la clé
                                        # DOIT exister, son absence est anormale