Issue #20669 has been updated by olleolleolle (Olle Jonsson). kjtsanaktsidis (KJ Tsanaktsidis) wrote in #note-1:
I agree it might be nice if Marshal had its own error class like `MarshalError` or some such. However, I don't really see why we need to _differentiate_ between different kinds of unmarshaling errors? Any one of these things from dalli ("marshal data too short", "incompatible marshal file format", ...) are in the realm of "a human needs to look at the data and figure out what went wrong", I would have thought?
I.e. it's useful to know that an exception did come from Marshal, but I don't think I quite see the value in knowing _what_ exception came from Marshal? Maybe I'm missing something obvious and you can enlighten me :)
Thanks! Alright, that'd scope it down, making the patch smaller and easier to deal with. I will make an edit to my proposal to be about adding a "is the data you are trying to load broken?" ArgumentError subclass called MarshalError. ---------------------------------------- Feature #20669: Add error classes to differentiate Marshal ArgumentErrors https://bugs.ruby-lang.org/issues/20669#change-109374 * Author: olleolleolle (Olle Jonsson) * Status: Open ---------------------------------------- Currently, Marshal.load raises ArgumentErrors on failure. In the memcache client Dalli, there is [a regular expression to check for a few of the ArgumentErrors that can be raised during Marshal.load](https://github.com/petergoldstein/dalli/blob/v3.2.8/lib/dalli/protocol/value...). In order to make it easier to work with, perhaps new individual error classes deriving from ArgumentError could be introduced in Marshal? Perhaps a MarshalError base class deriving from ArgumentError? Something backwards-compatible. [Dalli PR where another error message would be added](https://github.com/petergoldstein/dalli/pull/1008) -- https://bugs.ruby-lang.org/