Best Practices Question: Where should this exception be handled/rescued?

[Robby Grossman]

I built a heroku worker-scaling gem, which you can see here: http://github.com/freerobby/middle_management

Today it caused its first exception in my production app. RestClient timed out while talking to Heroku to set the proper number of workers.

My question is: what should the gem do in this situation?

Should it swallow the error so that its parent app never blows up when heroku fails to respond? Or should it honor that things really did blow up while it was doing its business, and leave it to the parent to deal with that accordingly?

If you were putting this gem in your project, which would you prefer?

[Robert Thau]

Robby Grossman writes:
> I built a heroku worker-scaling gem, which you can see here:
> http://github.com/freerobby/middle_management
>
> Today it caused its first exception in my production app. RestClient timed
> out while talking to Heroku to set the proper number of workers.
>

> My question is: what should the *gem* do in this situation?

>
> Should it swallow the error so that its parent app never blows up when
> heroku fails to respond? Or should it honor that things really did blow up
> while it was doing its business, and leave it to the parent to deal with
> that accordingly?

Well, I'm guessing that it's trying to add workers because requests of
some kind are getting backed up, and that if it fails, they keep
getting backed up. This is the sort of thing I'd generally want to
know about. (Though I'd also think about having it at least
optionally do a few retries before bombing out.)

rst

[Jay McGaffigan]

Exceptions are always interesting.

My general philosophy is to try not to allow exceptions to cross an
"API" border if possible.

the API/gem creator might want to determine:
a) what exceptions should I handle, and swallow (in the case of the
timeout should we catch it and put some retry logic in place)
b) What "error" conditions do I want to let the caller know about?
Should we let them bubble through and document that? "If you use this
gem here are the exceptions we have".
c) does the api have a standard place where I could catch, log any
useful state information, and rethrow any exceptions that I don't know
about? (this is basically the scenario where I didn't account for an
exception happening (hey we are only human can't catch everything) so
I am trying to catch "Exception" at the edge.

This is a constant topic for discussion on teams I have been on. But
the general consensus we've always come to is "swallowing" an
exception without reporting often makes it harder to diagnose an
issue.

Jay

> --
> You received this message because you are subscribed to the Boston Ruby
> Group mailing list
> To post to this group, send email to boston-r...@googlegroups.com
> To unsubscribe from this group, send email to
> boston-rubygro...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/boston-rubygroup
>

[Kevin Bedell]

> My question is: what should the gem do in this situation?

One way to handle this would be to make it configurable in some way so
that the user could choose the behavior they wanted. In some
situations I might want the ability to have the error swallowed
(especially if it really wasn't a fatal error for the entire app). On
the other hand, if it means my app might get taken down because it's
relying on resources your gem can't provide then it would be
appropriate to throw a well-documented exception that I can use to fix
the problem with.

Am I seeing this correctly?

The one thing I'd say is to make sure it's documented what the user
should do if they ever get the error you're throwing. Nothing's worse
than getting an exception and finding no help on what to do to fix the
issue.

-Kevin

--
Kevin Bedell
Independent Rails Developer
http://www.kbedell.com
@kbedell

[Jacob Burkhart]

To me this is corrolary to the problem of logging from a gem.

I would want the exception to be caught and retried. From the nature
of your gem it doesn't seem to make much sense to raise it up further.
BUT I would also expect the exception to be logged, and even forwarded
to whatver exception handling mechanism I use (aka hoptoad)

But how do you configure your gem to know that it should go to
rails.logger or merb.logger. It should neither assume nor guess, same
thing with the exception forwarding.

The obvious solution is to build your own MiddleManagement.logger
which consumers can configure. I've often done this, but it feels so
un-dry

Maybe we need a meta-logger gem whose sole purpose is to facilitate
the connection of logger from a component/gem to it's caller. Ditto
for exception notifying.

Ohhh and on the subject of API barriers I agree. But sometimes find
In practice that swallowing and reraising at the barrier can make it
harder to debug what actually went wrong (lose part of the stack trace
and perhaps original exception message)

Also, https://github.com/halorgium/rack-client is a pretty sweet
alternative to rest client. You could implement your API call retries
and timeouts as "client middlewares"

Sent from my iPhone