Concevoir sa hiérarchie, ou StandardError jamais Exception Designing your hierarchy, or StandardError never Exception

Les exceptions forment un arbre — et une frontière y compte.Exceptions form a tree — and one boundary matters in it.

Le № 1 rattrapait par type ; mais ce tri ne vaut que par la qualité de l'arbre qu'on lui donne. Toutes les exceptions descendent d'Exception. Juste en dessous, une frontière décisive sépare deux mondes : StandardError, où vivent les erreurs ordinaires d'un programme (et où doivent aller les tiennes), et tout ce qui est sous Exception mais hors de StandardError — les signaux système : Interrupt (le Ctrl-C de l'utilisateur), SystemExit, NoMemoryError. Ce ne sont pas des bugs à gérer, ce sont des ordres de l'extérieur. C'est pour ça que rescue, sans précision, s'arrête à StandardError : il laisse passer les signaux.№ 1 caught by type; but that sorting is only as good as the tree you give it. Every exception descends from Exception. Just below, a decisive boundary splits two worlds: StandardError, home to a program's ordinary errors (and where yours belong), and everything under Exception but outside StandardError — the system signals: Interrupt (the user's Ctrl-C), SystemExit, NoMemoryError. These aren't bugs to handle, they're orders from outside. That's why rescue, unqualified, stops at StandardError: it lets the signals through.

# l'arbre des exceptions — et la frontière qui compte
Exception                       # la racine de TOUT
├─ NoMemoryError                #   ┐
├─ SignalException → Interrupt  #   │ hors de StandardError :
├─ SystemExit                   #   │ les signaux système, à NE PAS rattraper
├─ ScriptError                  #   ┘
└─ StandardError                # ← le défaut de rescue, et la maison de TES erreurs
   ├─ RuntimeError              #   raise "msg" en crée une
   ├─ ArgumentError, KeyError   #   les erreurs « normales » d'un programme
   └─ NoMethodError, TypeError

raise "boom"               # => RuntimeError, donc < StandardError
RuntimeError.ancestors     # => [RuntimeError, StandardError, Exception, Object, ...]

rescue Exception avale le Ctrl-C de l'utilisateur.rescue Exception swallows the user's Ctrl-C.

C'est le piège le plus grave du volume, et il vient d'une confusion d'un seul mot. rescue Exception semble « plus sûr » que rescue StandardError — il attrape davantage. C'est justement le problème : il attrape ce qu'on ne doit jamais attraper. Le Ctrl-C lève une Interrupt, qui descend d'Exception mais pas de StandardError ; un exit lève SystemExit ; une panne mémoire, NoMemoryError. Rattraper Exception, c'est intercepter ces ordres venus de l'extérieur — et rendre un programme impossible à arrêter, ou masquer une mort imminente. Le défaut de Ruby est juste : rescue s'arrête à StandardError pour laisser les signaux faire leur travail.It's the volume's gravest trap, and it comes from confusing a single word. rescue Exception looks 'safer' than rescue StandardError — it catches more. That's exactly the problem: it catches what you must never catch. Ctrl-C raises an Interrupt, which descends from Exception but not StandardError; exit raises SystemExit; an out-of-memory, NoMemoryError. Rescuing Exception intercepts these orders from outside — making a program impossible to stop, or masking an imminent death. Ruby's default is right: rescue stops at StandardError to let the signals do their job.

# Le piège mortel : rescue Exception attrape AUSSI les signaux
loop do
  begin
    poll_queue
  rescue Exception => e     # Exception = la racine → attrape TOUT
    logger.warn(e)
    next
  end
end

# l'utilisateur appuie sur Ctrl-C → lève Interrupt (< Exception, hors StandardError)
#   … mais le rescue l'attrape et fait « next » : impossible de quitter.
# un SystemExit (exit) ? avalé aussi. Un NoMemoryError ? on tourne en boucle.

« Plus large » n'est pas « plus sûr ». En attrapant la racine Exception, ce rescue intercepte le Interrupt du Ctrl-C et le SystemExit d'un exit — l'utilisateur martèle le clavier et le programme refuse de mourir. On a confondu « gérer mes erreurs » avec « gérer tout événement », et capturé des ordres qui ne m'étaient pas adressés."Broader" isn't "safer". By catching the root Exception, this rescue intercepts Ctrl-C's Interrupt and an exit's SystemExit — the user hammers the keyboard and the program refuses to die. You've confused "handle my errors" with "handle any event", capturing orders not addressed to you.

Une classe de base par domaine — et des données sur l'objet, pas un message.One base class per domain — and data on the object, not a message.

Concevoir une hiérarchie d'erreurs suit deux principes simples. Un : une classe de base par domaine (Billing::Error < StandardError), dont héritent toutes les erreurs de ce domaine — rattraper la base attrape la famille entière, rattraper une feuille cible un cas. Deux : une exception est un objet, alors fais-lui porter des données structurées, pas seulement une chaîne. needed et available comme attributs, c'est un appelant qui réagit sans jamais parser un message. La hiérarchie n'est pas de la cérémonie : c'est ce qui donne au rescue par type du № 1 de quoi trier finement, et au code appelant de quoi décider.Designing an error hierarchy follows two simple principles. One: a base class per domain (Billing::Error < StandardError), inherited by every error in that domain — rescuing the base catches the whole family, rescuing a leaf targets one case. Two: an exception is an object, so make it carry structured data, not just a string. needed and available as attributes means a caller reacts without ever parsing a message. The hierarchy isn't ceremony: it's what gives № 1's rescue-by-type something to sort finely, and the calling code something to decide on.

module Billing
  # la RACINE de ta famille — une seule classe à rattraper pour tout prendre
  class Error < StandardError; end

  class CardDeclined < Error; end
  class GatewayDown  < Error; end

  class InsufficientFunds < Error
    def initialize(needed:, available:)
      @needed, @available = needed, available
      super("besoin de #{needed}, dispo #{available}")   # message lisible…
    end
    attr_reader :needed, :available                       # … ET données structurées
  end
end

begin
  charge(card)
rescue Billing::InsufficientFunds => e   # le cas précis : on a les données
  top_up(e.needed - e.available)         # pas de parsing de message !
rescue Billing::Error => e               # toute la famille d'un coup
  notify_support(e)
end
# rattraper la base prend tout le sous-arbre ; rattraper une feuille
# cible un cas — la hiérarchie te laisse choisir la granularité

Un repère de dosage : crée une classe d'erreur quand un appelant réagira différemment selon le cas, ou aura besoin des données qu'elle porte. Si personne ne va distinguer ni exploiter l'erreur, un RuntimeError avec un message clair suffit — la hiérarchie se construit là où le tri sert, pas par principe.A sizing cue: create an error class when a caller will react differently per case, or needs the data it carries. If no one will distinguish or use the error, a RuntimeError with a clear message is enough — the hierarchy is built where the sorting serves, not on principle.

Le rescue => e; nil fourre-tout : tous les bugs deviennent du silence.The catch-all rescue => e; nil: every bug becomes silence.

Le contre-exemple obligatoire du numéro, et peut-être l'anti-pattern le plus coûteux de Ruby. On entoure un calcul d'un rescue => e; nil « au cas où » — et on vient de transformer toute erreur en valeur nil muette. Une faute de frappe qui lève NoMethodError, une connexion qui tombe, un bug de logique : tout est avalé, rien n'est logué, la méthode rend nil comme si de rien n'était. Le bug ne disparaît pas, il se déplace : il refait surface trois couches plus loin, sous une forme méconnaissable, loin de sa cause — exactement le mal du Vol 3. La parade : ne rattrape que la famille que tu sais gérer, réagis, et re-lève le reste.The issue's mandatory counter-example, and perhaps Ruby's costliest anti-pattern. You wrap a computation in rescue => e; nil 'just in case' — and you've just turned every error into a mute nil. A typo raising NoMethodError, a dropped connection, a logic bug: all swallowed, none logged, the method returns nil as if nothing happened. The bug doesn't vanish, it moves: it resurfaces three layers away, in an unrecognizable form, far from its cause — exactly Vol 3's affliction. The remedy: rescue only the family you know how to handle, react, and re-raise the rest.

def total(orders)
  orders.sum(&:amont)        # faute de frappe : amont au lieu d'amount
rescue => e                  # le fourre-tout : rescue StandardError…
  nil                        # … et on AVALE tout, on rend nil
end

total(orders)   # => nil
# le NoMethodError n'a jamais levé, jamais été logué : il est devenu un nil
# muet qui casse trois couches plus loin — l'erreur loin de sa cause (Vol 3)

def total(orders)
  orders.sum(&:amount)
rescue Billing::Error => e   # on ne rattrape QUE ce qu'on sait gérer
  report(e)                  # on réagit…
  raise                      # … et on re-lève : la décision reste à l'appelant
end

# un vrai bug (NoMethodError, faute de frappe) n'est PAS un Billing::Error :
#   il n'est pas rattrapé, il remonte, visible, à sa cause. Le silence n'existe pas.