That's a good practice in many languages and systems.
It's a bit different here, as the standard way to handle things in Erlang (as I understand it) is for the function involved to crash, an error log to be made, and then the program to restart, usually seamlessly.
Linking this rule without discussion, context, or explanation is basically useless.
From a security perspective, this is also a bad idea. One of the golden rules of security is to validate all input. Anything which the programmers didn't expect and check for can potentially be used as part of an exploit.
the idea is to validate all input only once, when it's transformed from raw user-input data into structs/objects/etc used by your program. after that, assume it's valid.
Yeah I've seen a lot of people misunderstand defensive programming and validate the input to every method. Defensive programming style can create disastrously verbose code, particular in OO languages with people who don't really get OO design.
Comments
Most of the time I would precisely give the opposite advice. That's especially true if I had to deal with a large and/or legacy codebase.
It only really works if applied equally at all levels of the codebase.
That's a good practice in many languages and systems.
It's a bit different here, as the standard way to handle things in Erlang (as I understand it) is for the function involved to crash, an error log to be made, and then the program to restart, usually seamlessly.
Linking this rule without discussion, context, or explanation is basically useless.
Thanks for giving more context actually - this totally makes sense.
From a security perspective, this is also a bad idea. One of the golden rules of security is to validate all input. Anything which the programmers didn't expect and check for can potentially be used as part of an exploit.
the idea is to validate all input only once, when it's transformed from raw user-input data into structs/objects/etc used by your program. after that, assume it's valid.
Yeah I've seen a lot of people misunderstand defensive programming and validate the input to every method. Defensive programming style can create disastrously verbose code, particular in OO languages with people who don't really get OO design.