`rescue` also uses the match operator, which I found useful in the past when wrapping libraries that didn't expose a useful exception type hierarchy. In particular I seem to recall that the "pg" gem would throw `PG::Error`, with the actual error details from the Postgres server only accessible in the `message`. I wrote a little library that allowed me to create "virtual" exception types that could match based on the message or the result of an arbitrary proc (if the underlying exception class offered a `code` or `reason` attribute, for instance).
For all its (sometimes deserved) reputation as a big and complex language, Ruby is actually pretty good at making sure that language features are made with the same underlying building blocks, and thus two things that look similar probably work similarly as well.
Wow I've been programming Ruby for 15 years and didn't know `rescue` uses a match operator.
It's annoying when a library raises only one exception type for every error and the only difference is in the message. Matching on the message right in the rescue expression would be tremendously useful instead of parsing the message and deciding how to deal with it inside the rescue body.
It's a decade old and less than 100 lines so it might be more useful as an example than a gem. The last time I needed to do something like this I just rewrote the parts I needed. The ecosystem is just generally better about exceptions than it used to be, too.
For all its (sometimes deserved) reputation as a big and complex language, Ruby is actually pretty good at making sure that language features are made with the same underlying building blocks, and thus two things that look similar probably work similarly as well.