Zach M. wrote:
I use this philosophy when designing code with custom exceptions: Only
create exceptions that you (or other developers using your code) will
Also if you do go down the path of creating custom exceptions, I’ve
found that creating exceptions in the form of:
class MyError < StandardError
tends to be the cleanest, but of course your mileage may vary. Here’s a
link to a project I’m currently working on that defines it’s own
I hope this helps.
Thanks a lot, it was really a good idea to ask my question here since
this was something I didn’t think about on my own. Creating own classes
makes exception handling much more effective, so I think I will do that
in most cases.
Jonathan N. wrote:
I would use exception classes for all but trivial cases. I sometimes
use raise “message” for small projects as a placeholder for a better
error message or for debugging, but that’s about it… since the whole
idea of exceptions is to catch them, it is far better to be able to
‘rescue SomeTerribleException => e’ than to have to rescue Exception
=> e and have to test the exception string to find out what went wrong
(especially since the exception string can easily be changed without
thinking about it!)
In summary, exception classes.
Ok, that really sounds logic. Testing for exception strings would be
As to your other question, I’ll defer that to those who know better…
I just know that version control is your friend.
Ok, thanks for that, but we’re already using git and github.
Robert D. wrote:
On Thu, Apr 15, 2010 at 6:40 PM, Zach M. [email protected]
ï¿½class MyError < StandardError
I agree with most you say, but I took the habit to inherit from
RuntimeError rather than StandardError a long time ago. AAMOF I forgot
why? Does someone here recall the rationale?
Ok, that seems to be the next question. But I think I will inherit from
an own parent exception with most exceptions anyway, since it seems to
be reasonable to allow rescuing from all own exceptions and then I think
it doesn’t really matter which one I’ll choose as the parent of this