RmbRT said:

I use assertions as a way to validate untrusted inputs, such as user input or third party code.

Wow, that's like the opposite of where assertions should be used. Assertions are there to verify/document what you think you know, not to check user input. For untrusted input, you need a runtime check that gracefully handles failure without crashing the program.)

a light breeze said:
Wow, that's like the opposite of where assertions should be used. Assertions are there to verify/document what you think you know, not to check user input. For untrusted input, you need a runtime check that gracefully handles failure without crashing the program.)

No, my semantics/contract is that I expect to only receive valid input. The caller has to ensure validity. I just integrated into my interface a way to lazily delegate that validation into the internals by not using ok(i). And of course I also use plain assertions to do sanity checks internally. Basically, instead of throwing index out of range, it is better to terminate because the caller should already have thrown index out of range in the validation of the thing he passed to me — if the caller is at all interested in “clean” exception handling. But if the caller also doesn't care about clean exception handling, it's fine to just let the program crash.

And as a side note: my assertions do not call abort directly, they throw a custom exception type that can also be caught and printed. But if you don't explicitly handle that, it will crash and you can then go to the debugger.

I should maybe add that I am not interested in writing enterprise software, whatever that means. I don't care about clean code and all that other crap. I write my own stuff, and I want the process of writing and maintaining it to be as low-friction as possible. And so I don't do error taxonomies and graceful handling or whatever meme.