Thanks for the reply.
I think what you mentioned is the validation error, or validate the input for service.
How about an exception is raised when service object is doing the work?
Like item is out of stock when try to purchase, no item found when db fetch, etc.
Some of the exceptions we can avoid by pre-validate the input parameter, but some can only happen when we execute the code
Engineer at GitHub, graduate of + former teacher at Flatiron School. Cat lover, but I admit I have a dog. Supporting students and junior devs through https://www.break-in.tech/
Ah okay I see what you're saying. I think you can choose how to raise and handle exceptions as you would in any Rails model or service without violating the basic design outlined here. You have a few options available to you--use additional custom validators to add errors to the PurchaseHandler instance, or raise custom errors. I wrote another post on a pattern of custom error handling in similar service objects within a Rails API on my personal blog if you want to check it out: thegreatcodeadventure.com/rails-ap...
Thanks for the reply.
I think what you mentioned is the validation error, or validate the input for service.
How about an exception is raised when service object is doing the work?
Like item is out of stock when try to purchase, no item found when db fetch, etc.
Some of the exceptions we can avoid by pre-validate the input parameter, but some can only happen when we execute the code
Thanks
Ah okay I see what you're saying. I think you can choose how to raise and handle exceptions as you would in any Rails model or service without violating the basic design outlined here. You have a few options available to you--use additional custom validators to add errors to the
PurchaseHandlerinstance, or raise custom errors. I wrote another post on a pattern of custom error handling in similar service objects within a Rails API on my personal blog if you want to check it out: thegreatcodeadventure.com/rails-ap...Thanks!