4 ms·
But then your function should check if the value is within reasonable parameters. If it was an int at the function signature and you got -1 what would you expe
by raverbashing 5y ago
But then your function should check if the value is within reasonable parameters.
If it was an int at the function signature and you got -1 what would you expect to happen? It's the same thing.
- marginalia_nu 5y ago> But then your function should check if the value is within reasonable parameters How could you possibly check this using types that cannot represent what you are checking for?
- chromatin 5y ago> How could you possibly check this using types that cannot represent what you are checking for? `f(u32 a, u32 b) { assert a > b ... ` (if the hypothetical following operation is `a-b` as discussed higher in the thread)
- pjmlp 5y agoBetter ensure that assert is not turned off in release mode then.
- raverbashing 5y agoOne of the reasons I don't like asserts. Log the error and act accordingly, instead of believing this kind of issue only happens during development
- jstimpfle 5y agoHow do you "act" if you detected your logic is faulty? In many situations aborting is the best choice. If input data is faulty and the reason for that is not seen as part of your logic, then sure, log an error and skip. I used to define my own assert macro to "ensure" my asserts aren't disabled, but I don't bother anymore. There's nothing wrong with assert, and you needn't define NDEBUG. It's important to be aware that there are different situations, and not all warrant aborting, as described above. Another differentation is that there can be asserts that must be disabled in release builds for performance reasons, and others that won't affect performance and can stay enabled.