In my experience as programmer the main three sources of software crashes are:
- Forgot a null check on code that can return a null.
- Function has poorly defined flow and recursed until the stack crashed
- Didn't check for exceptions from code that throws exceptions, which is a crime in itself
- Forgot a null check on code that can return a null.
- Function has poorly defined flow and recursed until the stack crashed
- Didn't check for exceptions from code that throws exceptions, which is a crime in itself
Comments
It makes sense in I/O code which needs to potentially bail at one of a hundred possible positions, and, well, basically nowhere else.
Don't use it if you don't have a very good use.
The crashes tend to show up most frequently on queries: GetFoo(bar) unexpectedly nulls, software doesn't handle it, loud explosions follow.
It also returns a ForceNullCheck
Addlemoth does that a lot, if I actually need to verify that a query failed I can just do something like: if (obj == MapObject.Empty)
It's pretty crashproof!
A gamesdev example would be "A hits B, so A calls B to damage it, causing state changes in B." Chain reactions of behavior.
Behavioral definitions need to be first class and have limited scope of things that can change. Only modify within limited depth.