Raise/Rescue blocks about u-case HOT 8 CLOSED

@serradura , thank you very much for working with me on this! This definitely means that this lib is in-scope for us.

from u-case.

@ekampp you can return a failure in this case. e.g:

require 'bundler/inline'

gemfile do
  source 'https://rubygems.org'

  gem 'u-service', '~> 0.12.0'
end

class Divide < Micro::Service::Base
  attributes :a, :b

  def call!
    return Failure('numbers must be greater than 0') if a < 0 || b < 0

    Success(a / b)
  rescue => e
    Failure(e.message)
  end
end

#---------------------------------#
puts "\n-- Success scenario --\n\n"
#---------------------------------#

result = Divide.call(a: 4, b: 2)

puts result.value if result.success?

#----------------------------------#
puts "\n-- Failure scenarios --\n\n"
#----------------------------------#

result = Divide.call(a: 4, b: 0)

puts result.value if result.failure?

puts ''

result = Divide.call(a: -4, b: 2)

puts result.value if result.failure?

# :: example of the output: ::

# -- Success scenario --
#
# 2
#
# -- Failure scenarios --
#
# divided by 0
#
# numbers must be greater than 0

from u-case.

I saw that example as well. However, this behavior breaks regular, expected exception handling. This is very unexpected and is probably a blocking issue for us.

I would love to work with you on a change if you're open to this.

from u-case.

@ekampp I created a new example to help the understanding of how to handle exceptions/the program flow in case of different kinds of failures.

https://github.com/serradura/u-service/tree/master/examples/calculator

Gif showing the usage of this CLI (rake tasks).

Examples:

1. Handle exceptions outside of the service objects
2. Using different kinds of failures to handle the program flow

Question: Some of these examples help you on how to use the gem in your application?

from u-case.

I understand how you expect exceptions should be handled.

This, however, moves exception handling outside the actual service object. This conflicts with separation-of-concern and -responsibility.

The outside caller of the service object would have to know every error that the service object could cause. This also prevents the service object from reporting exceptions internally. Right?

from u-case.

@ekampp what do you think about a macro to enable an auto failure if happens an exception inside of a service object?

from u-case.

@ekampp could you share an example of your use case?

from u-case.

I'm not sure I'm clear on what you mean by this comment.

A bit more complex example could be something like this:

def call!
  # This could fail if the ID is invalid
  user = User.find id # id is the call parameter

  # This could fail with a different error, which means the calling class should now know about two errors.
  user.complex_calculation 

  # This could fail with a third type of error, which means that use calling class should now know about three, different errors.
  user.heavy_calculations
end

In this case, the calling class should know about three, different error states, which is relevant to the user object. So the calling class should know about errors from an object that's twice removed from the caller.

I think it would be cleaner to implement if one could add a rescue block inside the service to handle errors and report them to an exception handling service if needed.

from u-case.