Own exception classes

Ruby
1

Hi,

I’m working at a bigger private project with my brother now and I wanted
to ask, in which cases you recommend own exception classes.

One possibility would just be to use no own exceptions and just use
raise “message”. One other possibility would be to use an own exception
class for every situation. What do you recommend?

Another small question. This is my first “distributed” private project,
so we basically don’t meet very often and just implement our classes and
communicate via email sometimes. Are there any tips about this setting
or anything that we should pay attention to in order to avoid problems
in the future when the project gets bigger and more complicated?

Thanks in advance, greetings.
Bernhard B.

2

Hey Bernard,

I use this philosophy when designing code with custom exceptions: Only
create exceptions that you (or other developers using your code) will
rescue from.

So if I notice I’m creating exceptions that never get rescued in my own
code, and I don’t have a valid reason for why another developer would
rescue from it, I blast it.

Likewise, I treat:

begin
…
rescue StandardError
…
end

and

begin
…
rescue
…
end

As code smells, and refactor that by creating an exception.

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
end

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
exceptions.

I hope this helps.

–
Zach M.

3

On Thu, Apr 15, 2010 at 10:30 AM, Bernhard B.
[email protected] wrote:

I’m working at a bigger private project with my brother now and I wanted
to ask, in which cases you recommend own exception classes.

One possibility would just be to use no own exceptions and just use
raise “message”. One other possibility would be to use an own exception
class for every situation. What do you recommend?

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.

As to your other question, I’ll defer that to those who know better…
I just know that version control is your friend.

-Jonathan N.

4

Zach M. wrote:

Hey Bernard,

I use this philosophy when designing code with custom exceptions: Only
create exceptions that you (or other developers using your code) will
rescue from.

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
end

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
exceptions.
harvested/lib/harvest/api/base.rb at master · zmoazeni/harvested · GitHub

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
terrible.

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]
wrote:

�class MyError < StandardError
�end
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
exception.

5

On Thu, Apr 15, 2010 at 6:40 PM, Zach M. [email protected]
wrote:

class MyError < StandardError
end
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?

Cheers
R.

6

The problem (IIRC) with extending from Exception instead of
StandardError is that a plain ‘rescue’ statement will not catch bare
Exceptions, it catches StandardError (or is it RuntimeError?) by
default. To catch Exception (or descended classes), you need to
specify ‘rescue Exception’. But it’s a bit easier just to extend from
StandardError or RuntimeError, both of which are caught by a bare
rescue statement.

-Jonathan N.

7

On Apr 15, 2010, at 1:31 PM, Robert D. wrote:

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?

I’d be interested in hearing the rationale too. I actually forget my
argument for using StandardError, I only remember running into issues
(that I also don’t remember) doing

class MyError < Exception
…
end

I’ve seen smarter devs than me using StandardError, so I’ve been in
mostly emulation mode :slight_smile: