I'm mostly write Ruby and JavaScript. I was an organiser for the first Ruby conference in New Zealand, Kiwi Ruby, in 2017. In my spare time I'm usually knitting or playing video games.
We've used this pattern a bit at my work. One pro for throwing exceptions is that they integrate with your error reporting software if you have any (e.g. Rollbar or Raygun).
You can rescue the exception and have it report, then return a Result object, but I've found this to be a bit cumbersome, and have gone back to a pattern of raising and handling exceptions.
That's just our codebase though (Rails/custom Ruby framework microservices), so perhaps it's not a good fit for us, but might be for different apps :-)
I don't say that it is completely forbidden to use exceptions. Using exceptions is a great way to handle errors we don't know how to deal with. If its really an exceptional situation it should be logged somehow, for example in a error reporting software. In this case exceptions are great.
But for errors we know how to deal with it was for us a great benefit to use exceptions. For example we implemented a CSV Upload in C# and the CSV have to be valid, so the file have to pass many validation rules successfully. First we implemented it with exceptions => bad idea. One problem was that we want to display all broken validation rules and not only the first one.
Then we implemented a very basic Result object and tried it. We were satisfied with the code and so we also used this Result object in other components in our software. Until now we are very satisfied with it.
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.
We've used this pattern a bit at my work. One pro for throwing exceptions is that they integrate with your error reporting software if you have any (e.g. Rollbar or Raygun).
You can rescue the exception and have it report, then return a
Result
object, but I've found this to be a bit cumbersome, and have gone back to a pattern of raising and handling exceptions.That's just our codebase though (Rails/custom Ruby framework microservices), so perhaps it's not a good fit for us, but might be for different apps :-)
I don't say that it is completely forbidden to use exceptions. Using exceptions is a great way to handle errors we don't know how to deal with. If its really an exceptional situation it should be logged somehow, for example in a error reporting software. In this case exceptions are great.
But for errors we know how to deal with it was for us a great benefit to use exceptions. For example we implemented a CSV Upload in C# and the CSV have to be valid, so the file have to pass many validation rules successfully. First we implemented it with exceptions => bad idea. One problem was that we want to display all broken validation rules and not only the first one.
Then we implemented a very basic Result object and tried it. We were satisfied with the code and so we also used this Result object in other components in our software. Until now we are very satisfied with it.