You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Similar to collectiveidea/interactor#165, it might be nice to support a way to fail an interaktor with a particular type. It could be that the desire for multiple failure types is a symptom of having interaktors which are too complicated, but I'm leaning towards that not necessarily being true. If this were to be implemented I could see a new symbol argument being added to #fail! which represents the failure mode.
Take for example an interaktor which is invoked when a web request is received by an API. The interaktor is designed to create a new record in a database. That record may fail validation, or perhaps the record already exists. Typically error handling would be different between these two cases - maybe the API endpoint wants to send the right HTTP response code.
fail!(:validation,errors: record.errors)
fail!(:duplication,error: "The record already exists.")
It could also be useful to define these failure modes on the interaktor definition:
failure_mode:validation,:duplication
This would also aid in generating methods to check the error type, like #validation_error? or #duplication_error? in the example above. If they are defined, then specifying one when calling #fail! would be required.
The text was updated successfully, but these errors were encountered:
Similar to collectiveidea/interactor#165, it might be nice to support a way to fail an interaktor with a particular type. It could be that the desire for multiple failure types is a symptom of having interaktors which are too complicated, but I'm leaning towards that not necessarily being true. If this were to be implemented I could see a new symbol argument being added to
#fail!
which represents the failure mode.Take for example an interaktor which is invoked when a web request is received by an API. The interaktor is designed to create a new record in a database. That record may fail validation, or perhaps the record already exists. Typically error handling would be different between these two cases - maybe the API endpoint wants to send the right HTTP response code.
It could also be useful to define these failure modes on the interaktor definition:
This would also aid in generating methods to check the error type, like
#validation_error?
or#duplication_error?
in the example above. If they are defined, then specifying one when calling#fail!
would be required.The text was updated successfully, but these errors were encountered: