4 ms·
Perhaps, but that's an entirely different claim from the one made in the article (that Erlang can prevent such bugs).
by munchler 5y ago
Perhaps, but that's an entirely different claim from the one made in the article (that Erlang can prevent such bugs).
- macintux 5y agoThe claim was it prevents Heisenbugs.
- scns 5y agoIt does not prevent them. The reasoning is, that those bugs are so obscure, only occuring in vanishingly rare constellations, that finding and preventing them would be prohibitively hard/expensive.
- polack 5y agoSay 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).