Runtime warnings
Jul. 28th, 2018 12:10 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
jackThe other thought that inspired the previous post is that I didn't have a good concept in my mind for a sort of assert I want sometimes, of something I don't expect to usually happen, or don't expect to happen in testing, even if it may happen in other scenarios.
Say "unrecognised parameter in config file" as exhibited in some bug in a computer game that turned off a lot of the ai for many of the enemies that people were talking about recently.
Or "needed to retry file access/memory allocation/etc". Or "input file size is more than 1Gb".
You don't necessarily want to treat those as failures, because they might happen in real life and if so, you want to deal with them. You don't want to stop the function at the point where they occur. But you sort of want to mark the behaviour somehow, because it will *usually* indicate a bug while developing.
I'm not sure how to think of these. Maybe "development only asserts"? Or "warnings which are not triggered, but counted and printed out at program termination during development and included with output of tests"?
Say "unrecognised parameter in config file" as exhibited in some bug in a computer game that turned off a lot of the ai for many of the enemies that people were talking about recently.
Or "needed to retry file access/memory allocation/etc". Or "input file size is more than 1Gb".
You don't necessarily want to treat those as failures, because they might happen in real life and if so, you want to deal with them. You don't want to stop the function at the point where they occur. But you sort of want to mark the behaviour somehow, because it will *usually* indicate a bug while developing.
I'm not sure how to think of these. Maybe "development only asserts"? Or "warnings which are not triggered, but counted and printed out at program termination during development and included with output of tests"?
no subject
Date: 2018-07-28 02:27 pm (UTC)Although actually, "Unrecognised parameter in config file" does sound like the kind of thing where the program should refuse to run until the config file is fixed.
no subject
Date: 2018-07-30 10:10 am (UTC)I didn't really go into the details here, but I think the reason for this is that if you have different versions of the software that may be upgraded/downgraded or need to interoperate with each other, you may end up with a config option from a more-recent version of the software, which contains entries unknown to the older version of the software, but having the older version ignore them is what you want.
I guess, ideally, tagging the options with which version they're supposed to be valid for would be better, but I only just thought of that, it doesn't seem common.