New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
New exception classes #837
Comments
The intended meaning is to prefer the standard library exceptions when introducing custom ones won't really add any benefits.
File IO exceptions also come to mind (e.g. In general I agree that the guideline can be improved, so feel free to take a stab at it. |
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 anInteger
instead of aString
,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 ofStandardError
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 text was updated successfully, but these errors were encountered: