On Sat, Nov 17, 2012 at 4:47 AM, tamouse mailing lists
<tamouse.lists / gmail.com> wrote:
> On Fri, Nov 16, 2012 at 6:27 AM, Robert Klemme
> <shortcutter / googlemail.com> wrote:
>> On Fri, Nov 16, 2012 at 9:27 AM, tamouse mailing lists
>> <tamouse.lists / gmail.com> wrote:
>>
>>> Is this a good way to use exceptions? Having an insufficent balance
>>> might be something the user finds exceptional, but I'd think it would
>>> be a standard sort of handling for a bank applicaion...
>>
>> Depends on how you implement it:
>
> I know the right answer to every question is "It depends" :)

Ah, I see you learned the most important lesson! ;-)

>> if you have the option to query the
>> current balance and define that a withraw operation is only allowed
>> with sufficient funds then you throw an exception.  If OTOH you define
>> that withdraw will return success then you have a boolean return
>> value.  Both approaches are legal and feasible.
>
> I guess I'm looking for some kind of guidance to generalize this.
>
> My understanding is that one only uses exceptions for things which the
> app finds exceptional,

... which is a kind of tautological statement. :-)

> meaning things which it cannot or should not be
> dealing with, which in some cases may depend on the business practices
> and policies one is implementing.

Yes.  And this also depends on context and design philosophy.  For
example, in Java you will get an exception when accessing an array or
an ArrayList with an illegal index.  In Ruby you just get nil from
Array if the index was out of range.  This makes perfectly sense given
that the normal iteration method in Ruby is via #each which ensures
you only get to see elements in the Array and in Java you have to
externally iterate with an index or Iterator instance.

OTOH you will get an exception in Ruby if the type is not an integral
type or the numeric value is too large.

> Do you (or anyone else who'd like to chime in!) have a ... set of
> heuristics, maybe? .. that help you know when it's appropriate and
> when it's not?

I can see these categories of errors where an exception seems appropriate to me:

1. programmer errors
   - invoking methods which are not there
   - invalid arguments passed to methods (type errors, range errors)
   - invalid arguments passed which would invalidate the class invariant
   - calling methods at the wrong time i.e. when the instance is not
in the proper state for the method call (e.g. you must invoke #open on
something before you can invoke #write, you need to obtain some form
of lock before you are allowed to work with an instance)

2. exceptional conditions outside the program
   - technical IO errors (disk and network)
   - memory exhausted

There are probably more but this is what comes to mind off the top of my head.

> The reason I ask is not merely academic. I see in code many places
> where it is raising and exception, and then the rescue code does
> something like this:
>
> rescue Exception
>
>    # blah blah
>
> end
>
> In other words, they know an exception might be raised, but they trap
> evey possible exception, rather than a specific one. I'm worried (?)
> (thinking) that use of raising exceptions might be a little too easily
> decided upon as the answer, and if I should maybe push back on such
> implementations...

That's really hard to tell without more context. :-)

> Thanks, so much, Robert. :)  And I am going to check out your web site
> right now.

You're welcome!

Kind regards

robert

--
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/