New exception classes
marcandre opened this issue · 1 comments
Prefer the use of exceptions from the standard library over introducing new exception classes.
I feel this is not quite accurate.
Indeed, a gem should use standard library exceptions in case the gem is called with invalid inputs (e.g. TypeError
if called with an Integer
instead of a String
, ArgumentError
, IndexError
, etc.). Typically these are never rescued.
But when something proper to the gem happens, instead of raising a RuntimeError
it should have its own subclasses of StandardError
for that gem (with potentially a base class for the gem). E.g. ::Parser::SyntaxError
, ::Parser::ClobberingError
. Typically these may be rescued by the dependents of the gem.
May I amend the guide?
The intended meaning is to prefer the standard library exceptions when introducing custom ones won't really add any benefits.
Indeed, a gem should use standard library exceptions in case the gem is called with invalid inputs (e.g. TypeError if called with an Integer instead of a String, ArgumentError, IndexError, etc.). Typically these are never rescued.
File IO exceptions also come to mind (e.g. IOError
). That being said - when the standard library doesn't cut it, it should be obvious one needs to introduce additional exception types.
In general I agree that the guideline can be improved, so feel free to take a stab at it.