I love this approach but one thing I couldn't realize is how to handle exceptions. I don't like writing try/catch block into handler method. Doing some research about it I found the functional programming and it looks very clean the way it handles exceptions using the Rail pattern.
It is still confuse for me but I'm practicing and learning about functional programming.
Yes! the railway-oriented is interesting; things like F# are very cool.
In those scenarios, IMHO, categorization in error handling is important. For example: 1) non-functional validations and 2) business validations. In the first case, for (1), it can be solved through middlewares and pipelines. And for (2), you can use the notification pattern; libraries like Fluent Validation could help. Anyway, it depends...
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I love this approach but one thing I couldn't realize is how to handle exceptions. I don't like writing try/catch block into handler method. Doing some research about it I found the functional programming and it looks very clean the way it handles exceptions using the Rail pattern.
It is still confuse for me but I'm practicing and learning about functional programming.
Fluent Results Pattern ;)
enterprisecraftsmanship.com/posts/...
Yes! the railway-oriented is interesting; things like F# are very cool.
In those scenarios, IMHO, categorization in error handling is important. For example: 1) non-functional validations and 2) business validations. In the first case, for (1), it can be solved through middlewares and pipelines. And for (2), you can use the notification pattern; libraries like Fluent Validation could help. Anyway, it depends...