3 ms·
>What exceptions do is enforcing that your working set does not have to encode any erroneous states, preventing the combinatorial explosion of states, which of
by fckgnad 4y ago
>What exceptions do is enforcing that your working set does not have to encode any erroneous states, preventing the combinatorial explosion of states, which of course is a net win, there isn't really any valid argument that can be made against it.
A combinatorial explosion of states is not a bad thing. Integers in C++ for example have 4294967296 possible states. Programming is not descending into complete chaos just because one of the fundamental types has more possible states then the human brain is capable of handling.
You're describing using exceptions as a catch all fail-safe. It's isomorphic to the the "else" statement in your standard if-else structure which is one of the techniques people use to handle the 4294967296 possible states of int. See example code below on this amazing technique I use to deal with 4294967296 possible branching possibilities:
if(x == 0){
// do something
} else {
//handle all 4294967295 other states.
}
>Where people are debating is that sometimes you do want errors to be part of your working set, in which case you shouldn't use exceptions. But choice is difficult for some, especially those seeking absolute doctrines.
In every other engineering field you do want this as part of your design. You want to know about every possible state your system can be in and handle the states explicitly. Unknown states that are not explicitly encoded into an engineering design is typically a Bad thing.
That is not to say you should design your system and not acknowledge the possibility of an unknown state. You need fail-safes like exceptions to handle these unknown states. But make no mistake, it's not good to have fail-safes regularly executing to catch a bunch of states you failed to encode into your system.
A good example of this is corrected design of the MCAS on the boeing 737 max. The MCAS should not use a fail-safe handle the crash modes we are now well aware about. The MCAS should explicitly be encoded with our knowledge about the new possible error modes. I certainly don't want to sit in a plane where this hasn't been done.
I will also say that much of programming doesn't need the level of safety other engineering products need. Shipping products faster at the cost of quality is something unique to software as the quality can be improved AFTER shipping, so that is not to say your way of using exceptions to catch unknown states (or states not explicitly encoded into the system) is completely wrong; but is certainly not best practice or ideal.