Thanks for the responses, I am a lot more clear on what options are more appropriate for each particular situation.

Mark Ratjens <mailto:[email protected]>
28 April 2013 12:09 PM
It does depend, of course. But Owen stating that exceptions "should be just for a condition that should never really occur under the normal workflow" and Sebastian's "that is supposed to be called only once" are not that different, which is why I suggested the exception approach, based on what Sebastian seemed to be asking for. It comes down to risks and consequences. If you just return a value, you run a very real risk that calling code never looks at it and there's no obvious problem to the caller, at least not immediately. You may end up with errors somewhere else, then you have a more exotic debugging problem on your hands. If there's no risk of that happening, then you're really saying that returning a value adds extra complexity for no reason. In that case, idempotence is the simplest thing that can possibly work.





--


*Mark Ratjens*
*Co-founder, Habanero Software*
*
*
*
*
Sydney, Australia
[email protected] <mailto:[email protected]>
@MarkRatjens <mailto:[email protected]>
www.habanerohq.com <http://habanerohq.com>
+61 414 159 357
--
You received this message because you are subscribed to the Google Groups "Ruby or Rails Oceania" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/rails-oceania?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.


owen <mailto:[email protected]>
28 April 2013 4:43 AM
It depends on the use case really. Impotency is great, but the user of the gem might need to know if it's been done before. I wouldn't use an exception, that should be just for a condition that should never really occur under the normal workflow. An easy solution may be to make the method idempotent and add another method to your api so if the user of your api needs to know if it's been done before, they can e.g.

  if !user.done_something?
    user.do_something
  else
    puts "it's already been done"
  end

or if the user of your gem doesn't really care, they can just call the user.do_something and carry on (especially without having to handle some frustrating exception condition that they dont care about).

But it all depends... if you have lot's of different possible results from do_something, then you may want to return some object that can be inspected. If it should never happen (like the file not existing) then you may want to throw and exception and force the user of you api to deal with it.



--
You received this message because you are subscribed to the Google Groups "Ruby or Rails Oceania" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/rails-oceania?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.



--
You received this message because you are subscribed to the Google Groups "Ruby or 
Rails Oceania" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/rails-oceania?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.


<<inline: postbox-contact.jpg>>

<<inline: postbox-contact.jpg>>

Reply via email to