Handling errors about light-service HOT 6 CLOSED

@padi: Congratulations! You have taken LightService much farther than I have.

Why not handling the exception in the actions right away and failing the context with set_failure! in the rescue block? I am not a big fan of bubbling up the exception to the very top and handling it there.

So in the code you'd do this:

class SomeAction
  include LightService::Action
  executed do |context|
    begin
      # do some action
    rescue AnotherError => e
      # do something unique
      context.set_failure! "unique message"
    end
  end
end

Do you think this would work?

from light-service.

I guess I have to supply more info regarding our use case (updated the SomeOrganizer class to reflect that the organizer is a resque job)

Consider the following:

1. We're making use of Resque's failure backend feature to handle our errors. With that, it is imperative that we raise errors to be able to send it to multiple backends, e.g. notify developers via email that some error occurred and record the failure on redis at the same time.
2. We want to make sure that the error messages supply helpful information, e.g. along with the error, send the id of specific record when the error occurred, so we re-raise the error with a custom message.
3. Typically, we have 10 or more actions in one organizer, half of which are dealing with having to communicate to multiple APIs (using a different client gem for each api).

So to answer your question, we've been using that route and there can be a problem with that:

It does not enforce the rescue for all actions that should rescue the same type of custom error. Our specific error was an error raised by a 3rd party client gem that's used in multiple steps. If someone adds an action that uses the same gem, and forgets to add begin...rescue (which indeed happens sometimes), and an error happens, no one is notified that an error occurred and nothing is recorded (except probably in the logs).

Instead of writing the error catching logic once-and-for-all, we end up having to remember that whenever we have to deal with this client gem in a new action, we should include this begin-end logic.

I'm not keen on writing code for this until I figure out for myself that this is indeed a feature needed by LightService. If this is too special for a use case, I might have to create another gem, e.g. light-service-resque or something like that.

from light-service.

Why don't you have a facade for the external library? That way the facade could handle the exceptions.

Anyway, since this is an additive change I would have no problem to include this in the project. I think what you propose is clean and elegant.

We just need to make sure this feature is clearly documented in the wiki.

Thanks!

from light-service.

@padi: Are you working on this? Can I close this issue?

from light-service.

@adomokos not at the moment. Just used ActiveSupport::Rescueable instead. Closing.

from light-service.

Thanks!

from light-service.