Raising Excepitons

[John W. Long]

Hi,

I'm curious. In code I often raise my own exceptions with:

raise "custom error message"

When is it a good idea to subclass and create my own error class? So far
I've never needed to pass along custom information (other than the message).
It seems like it might make testing better:

assert_raises(MyError) { ... }

instead of:

assert_raises(RuntimeError) { ... }

Are there any other advantages? Are there times when it's convention to
create your own?

___________________
John Long
[url]www.wiseheartdesign.com[/url]

[David Naseby]

>-----Original Message-----

>From: John W. Long [mailto:ws@johnwlong.com]

>When is it a good idea to subclass and create my own error
>class?

Your testing example was good, and similarly, it also aids in debugging down
the line. For example, if you have a method that opens a file and
manipulates the data, its generally a good idea to know if an exception
coming out of that method is related to the file ops or due to some use of
the standard library, or from a defined bad operation from your code (error
condition). Defining a derived exception class is a bit safer for client
code to handle, rather than just parsing the exception message.

David

[Robert Klemme]

"David Naseby" <david.naseby@eonesolutions.com.au> schrieb im Newsbeitrag
news:C1B5ED61365AD511805500D0B7B697C633DAEF@sydeon e.eonesolutions.com.au...

> >-----Original Message-----
> >From: John W. Long [mailto:ws@johnwlong.com]

>

> >When is it a good idea to subclass and create my own error
> >class?

>
> Your testing example was good, and similarly, it also aids in debugging

down

> the line. For example, if you have a method that opens a file and
> manipulates the data, its generally a good idea to know if an exception
> coming out of that method is related to the file ops or due to some use

of

> the standard library, or from a defined bad operation from your code

(error

> condition). Defining a derived exception class is a bit safer for client
> code to handle, rather than just parsing the exception message.

Not only is it "a bit safer" but it's much cleaner (and maybe faster,
too). Relying on the exception type is better, because it makes handling
of those exceptions easier (especially if they need to be dealt with at
different levels of the application). And just think about
internationalized error messages...

robert

[Gennady]

It is also convenient to define your own exception, even without any
extra information besides the message, if you need to raise it in
several places. In the very least it removes the message duplication
and facilitates in debugging.

Gennady.

Sincerely,
Gennady Bystritsky


On Nov 12, 2003, at 8:04 PM, David Naseby wrote:

>

>> -----Original Message-----
>> From: John W. Long [mailto:ws@johnwlong.com]

>

>> When is it a good idea to subclass and create my own error
>> class?

>
> Your testing example was good, and similarly, it also aids in
> debugging down
> the line. For example, if you have a method that opens a file and
> manipulates the data, its generally a good idea to know if an exception
> coming out of that method is related to the file ops or due to some
> use of
> the standard library, or from a defined bad operation from your code
> (error
> condition). Defining a derived exception class is a bit safer for
> client
> code to handle, rather than just parsing the exception message.
>
> David
>
>