4 ms·
Say you have an application that takes user input, validates it and then try to add it to the current state. If there is a bug in the validation so that 0 is al
by polack 5y ago
Say you have an application that takes user input, validates it and then try to add it to the current state. If there is a bug in the validation so that 0 is allowed as input, but later when you try to add it to the current state you divide by 0.
In Java you would explicitly handle this case with a catch and take action on a "division by zero exception". In Erlang you would just let the process crash (and log the reason so bug can be fixed) and restart the state to what it was before the erroneous input, no matter what bug/case the wrong input triggered. By having this generic handling you will make a really resilient system since you don't have to handle every possible bug on a case-by-case basis.
What would be the advantage of handling this case in the Java defensive programming approach? Maybe someone will catch the error and return/introduce null to the state? Or BigDecimal.ZERO? Then you might end up in an unexpected state for all subsequent requests.
- scns 5y agoWell, division by 0 could be handled with pattern matching without crashing. Excuse my rusty pseudoerlang. (edit) formatting handle_zero(data, 0) -> {:error, "division by zero"}, handle_zero(data, _) -> {:ok, transform(data)}. handle_input(data) -> handle_zero(data, data.divider).