On Sat, Nov 17, 2012 at 4:47 AM, tamouse mailing lists <[email protected]> wrote: > On Fri, Nov 16, 2012 at 6:27 AM, Robert Klemme > <[email protected]> wrote: >> On Fri, Nov 16, 2012 at 9:27 AM, tamouse mailing lists >> <[email protected]> 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/ -- You received this message because you are subscribed to the Google Groups ruby-talk-google group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at https://groups.google.com/d/forum/ruby-talk-google?hl=en
