Nikita, thank you so much for your article. I ran into it looking for discussion on the topic. We use Marshmallow for validation and until version 3 it had a very simple mechanism of returning (valid_data, errors). In version 3 they decided to use exception upon errors instead. While it was easy to work around and wrap the call, It was a much better design in the original approach. I liked the design so much that I've used it myself in several designs.
I believe you are correct and I hope more developers come around to this way if thinking.
Code that is doing large sequences of data manipulation does not want to be halted or even thrown off course due to a single error. It wants to note it, store some details, and move on.
Exceptions are great in IO, memory, resource issues, etc. In my opinion they should be avoided in designs such as Marshmallow where errors are expected.
Nikita, thank you so much for your article. I ran into it looking for discussion on the topic. We use Marshmallow for validation and until version 3 it had a very simple mechanism of returning (valid_data, errors). In version 3 they decided to use exception upon errors instead. While it was easy to work around and wrap the call, It was a much better design in the original approach. I liked the design so much that I've used it myself in several designs.
I believe you are correct and I hope more developers come around to this way if thinking.
Code that is doing large sequences of data manipulation does not want to be halted or even thrown off course due to a single error. It wants to note it, store some details, and move on.
Exceptions are great in IO, memory, resource issues, etc. In my opinion they should be avoided in designs such as Marshmallow where errors are expected.
Thanks a lot, Jeff!