|
|
|
SearchCategories
Books by the AuthorTwitter AccountOther Ruby Projects |
Summoning Error Classes As Needed
Posted over 3 years ago
in Ruby Tutorials and Ruby Voodoo.
In the past, I've written a lot of code like this:
I have a new strategy I've been using for code like this and it has really been working out well. Here is how I do the same thing today:
Let's discuss how this works. The In this version, I just check to see if the constant name ends in The building of the That's the how, but let's talk a little about the why. When I showed this trick to a friend, he complained that these summoned errors are not easily RDoced. That's true, but I've actually found this is improving my documentation instead of hurting it. Raise your hand if you tend to click on all the errors listed in the API documentation and read about those. Yeah, I don't either. With those gone (and note that I explicitly disabled RDoc for my hack), I just add details about the A final bonus of this technique is that it even works if you are dynamically generating error names in some code, say with |
|
|
|
A trick that brings my favorite method, Class.new, together with my favorite family of methods, const_*? Good show!
I like the implementation as a concept, but I am concerned about what the results would be for client code. This would seem to encourage the creation of an arbitrarily large number of Error classes. To my mind the goal of raising an error is to have some other part of the program catch it and do something intelligent to fix it. I, therefore, only create a new error class when I think the error can be handled somewhere. This being the case, I find a list of all potentially handleable errors useful, even if I don't click on them in the rdocs.
I guess my question is, why not just raise a RunTimeError or some other already defined Error class and use the properties of the Error class to give more detail?
:StarTrader -- const_set means that the newly generated Error classes won't remain anonymous; you'd be able to rescue them by name.
This blog post from Jamis Buck may interest you:
http://weblog.jamisbuck.org/2007/3/7/raising-the-right-exception
Also note that typo's won't be caught, causing more subclasses of RuntimeError to be created.
Example:
now you have two exceptions.
Maybe something like this would be more suitable, although not as concise.