4 ms·
This post takes a very narrowed point of view on errors, i.e. mostly errors addressed to developers: compiler errors, runtime errors/exceptions/crashes, etc. T
by nivertech 4y ago
This post takes a very narrowed point of view on errors, i.e. mostly errors addressed to developers: compiler errors, runtime errors/exceptions/crashes, etc.
There are many different kinds of errors, but they can be roughly divided into two categories: business errors and technical errors.
Business errors are not really an errors, but rather alternative business outcomes.
Paraphrasing Kellyanne Conway: business errors are alternative results;)
Something like Saga pattern or ACID transactions can be used to handle this kind of errors.
Technical errors are also a huge category, the most important properties are whether they can be reported to the end-user, or they make sense to developers only. Also are they retriable or not.
Lastly, some programming languages/runtimes/VMs reporting lots of ignorable errors, e.g. look at the log of any JVM application, you will see lots of exceptions, same in the browser's JS console. Even in Erlang/Elixir logs you will see supervisor errors, etc. IMO it make sense to expect clean logs in case of normally functioning application, but that's not the case for most development environments today.