Skip to content
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

Open
marcandre opened this issue Aug 11, 2020 · 1 comment
Open

New exception classes #837

marcandre opened this issue Aug 11, 2020 · 1 comment
Labels

Comments

@marcandre
Copy link
Contributor

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?

@bbatsov
Copy link
Collaborator

bbatsov commented Aug 12, 2020

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants