3 ms·
Perhaps you're just missing the complexity of the real world? I'm working on quite big finite element desktop applications, where alone the reading of the data
by dan00 9y ago
Perhaps you're just missing the complexity of the real world?
I'm working on quite big finite element desktop applications, where alone the reading of the data can take up quite a bit of time. The user can then apply all kinds of different operations on this data and if one of these operations fails because of a null pointer - then sure, the code is wrong - but nevertheless the user doesn't want to loose all of his previous work and wants to be able to save the changed data.
Sure there're cases that a failed operation might have corrupted the data, but you just can't tell this in every case, and often the data is still valid and only the operation couldn't be applied.
If I've learned something over the years, then that there's not one solution that works for all cases.
- jstimpfle 9y agoSo you weren't expecting bad user input? Bad for you! This is called validation, and in a validation routine you expect bad invalid data. Check inputs at the trust boundaries, and off you go. Note this is NOT about just null pointers but about integrity in general.
- dan00 9y agoWell, if you want a serious discussion then don't imply something just to be able to make a point. But if you just want to win an argument: here you go.
- tzahola 9y agoThen you should run the risky operations in a different process. It will not only protect you from the operation crashing your main program, but also from data corruption if you use readonly access for the shared data.