6 ms·

I agree, Example 1 is a little weird, but i wouldn't call it wrong. Example 2 is just bad. In example 3 some people compile with exceptions turned off. Assert

I agree, Example 1 is a little weird, but i wouldn't call it wrong. Example 2 is just bad. In example 3 some people compile with exceptions turned off. Asserting on new isn't a problem. Also, "The assert is supposed to check for bad code, not check errors" -- well new returning NULL would be bad code :) Also, in general, if malloc fails asserting is usually your best option, it's basically impossible without heroic efforts to recover from malloc failing, as almost anything you might do in recovery might try another mallocing! Also, example 4 is (in my opinion) fine. I often 'assert' in programs when I have no idea what else to do. Asserting is certainly better than the alternative of just carrying on in a bad state, and fixing up the problem might be hard (I notice there is no suggested "fix" here). Also, many of these comments related back to the original code by 'Satoshi', which makes the final comment, about 1x and 10x programmers hilarious: Yes, of course Satoshi was a '1x' programmer, how date we let them near the bitcoin source code, imagine how much better it would have been without them...

cillian64 10y ago
The idea is that assert is for helping developers catch mistakes, not as a way of dealing with errors when users run the program. Malloc failing or input being invalid are not (necessarily) signs of bugs in the program, and so should not be handled using assertions. Even if the handling is just ending the program, that should be done using exceptions or "return -1", not by asserting false. Asserts and other error handling (exceptions) have different semantics. Disabling asserts says "I believe this code has no bugs", not so unreasonable for a stable release. Disabling exceptions says "I believe nothing unexpected will ever happen", which is several notches crazier.
- CJefferson 10y ago
  I think we just disagree on what asserts are for. I consider asserts to mean "If this isn't true, there is no way to continue. Something has gone horribly wrong. Just Stop. Now." I suppose I could make up a new function, called say 'check', which basically did exactly the same thing as assert. But why bother? assert is already there and does what I want.
  - dllthomas 10y ago
    Because it's context dependant that assert does what you want. If there's no way to continue, you should also be ending the program in production builds, probably with a prettier error message.

cillian64 10y ago

The idea is that assert is for helping developers catch mistakes, not as a way of dealing with errors when users run the program. Malloc failing or input being invalid are not (necessarily) signs of bugs in the program, and so should not be handled using assertions. Even if the handling is just ending the program, that should be done using exceptions or "return -1", not by asserting false. Asserts and other error handling (exceptions) have different semantics. Disabling asserts says "I believe this code has no bugs", not so unreasonable for a stable release. Disabling exceptions says "I believe nothing unexpected will ever happen", which is several notches crazier.

CJefferson 10y ago
I think we just disagree on what asserts are for. I consider asserts to mean "If this isn't true, there is no way to continue. Something has gone horribly wrong. Just Stop. Now." I suppose I could make up a new function, called say 'check', which basically did exactly the same thing as assert. But why bother? assert is already there and does what I want.
- dllthomas 10y ago
  Because it's context dependant that assert does what you want. If there's no way to continue, you should also be ending the program in production builds, probably with a prettier error message.