Prev: [ANN] PDF::Writer officially retired in favor of Prawn
Next: Deep Clone of array?
From: Bernhard Brodowsky on 15 Apr 2010 12:30
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 Brodowsky
--
Posted via http://www.ruby-forum.com/.

From: Zach Moazeni on 15 Apr 2010 12:40
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.
http://github.com/zmoazeni/harvested/blob/master/lib/harvest/api/base.rb#L23

I hope this helps.

--
Zach Moazeni
http://simplechatter.com
--
Posted via http://www.ruby-forum.com/.

From: Jonathan Nielsen on 15 Apr 2010 12:41
On Thu, Apr 15, 2010 at 10:30 AM, Bernhard Brodowsky
<brodowsb(a)student.ethz.ch> 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 Nielsen

From: Robert Dober on 15 Apr 2010 13:31
On Thu, Apr 15, 2010 at 6:40 PM, Zach Moazeni <zach.moazeni(a)gmail.com> wrote:
<snip>
>  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.

--
The best way to predict the future is to invent it.
-- Alan Kay

From: Bernhard Brodowsky on 15 Apr 2010 13:52
Zach Moazeni 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.
> http://github.com/zmoazeni/harvested/blob/master/lib/harvest/api/base.rb#L23
>
> 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 Nielsen 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 Dober wrote:
> On Thu, Apr 15, 2010 at 6:40 PM, Zach Moazeni <zach.moazeni(a)gmail.com>
> wrote:
> <snip>
>> �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.
--
Posted via http://www.ruby-forum.com/.

 |  Next  |  Last
Pages: 1 2
Prev: [ANN] PDF::Writer officially retired in favor of Prawn
Next: Deep Clone of array?