Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Assert(): A Modern How To

fiberfs.io

Post reply on HN
Print view View original

11–20 of 33 posts

Re: Assert(): A Modern How To

#11

Post by lelanthran »

crabbone wrote: post #9

There's a whole big contentious point that the author completely ignored: using assertions in tests (like unit-tests). Some unit testing frameworks expect their users to use assertions to do the job, others are very much against it because they want to separate between the failures of the system under test from failures of the test. (If that matters, I'm in the later camp). * * * I also think that the article confuse…

> Some unit testing frameworks expect their users to use assertions to do the job, others are very much against it because they want to separate between the failures of the system under test from failures of the test. (If that matters, I'm in the later camp).

How useful is this distinction in practice? A failing test is going to examined in detail and that examination is going to reveal whether the system under test failed or if the test itself failed.

I guess I am asking, when is this distinction useful?

Re: Assert(): A Modern How To

#12

Post by 7bit »

rramadass wrote: post #3

Not this again ... Assertions should only be thought of as predicates on state space to ensure program correctness. Everything else is just a corollary. Some relevant past comments of mine here - https://news.ycombinator.com/item?id=48358691

If you say so it must be law

Re: Assert(): A Modern How To

#13

Post by benj111 »

eps wrote: post #10

> Can assertions be used in production? Yes > What should I be asserting on? Invariants > Can I customize how assert behaves? It should abort the program, logging the stack and whatever the context you pass into in, printf-style. If it doesn't abort, it just buries the issue of the program being in incorrect internal state. It should never be OK.

I think part of the problem is that assert is used for different things.

You can use assert to cover a case that should never happen, you can also use assert to catch programming errors during development.

It's arguable that you don't want the second group in a production build. That should have been caught in testing.

But then there's the use where it's a lazy person's if statement. Instead of dealing with the issue assert it. I'm undecided whether this is a net good. Would the test have been implemented anyway?

Re: Assert(): A Modern How To

#14

Post by rramadass »

7bit wrote: post #12
rramadass wrote: post #3

Not this again ... Assertions should only be thought of as predicates on state space to ensure program correctness. Everything else is just a corollary. Some relevant past comments of mine here - https://news.ycombinator.com/item?id=48358691

If you say so it must be law

Ha, Ha ...

I have pointed to previous discussions with other HN users where the logic and rationale behind my "say so" are given. If you actually cared to read them you will find quite long back-and-forth on formal methods and a whole lot of references for edification.

Re: Assert(): A Modern How To

#15

Post by twhitmore »

lelanthran wrote: post #11
crabbone wrote: post #9

There's a whole big contentious point that the author completely ignored: using assertions in tests (like unit-tests). Some unit testing frameworks expect their users to use assertions to do the job, others are very much against it because they want to separate between the failures of the system under test from failures of the test. (If that matters, I'm in the later camp). * * * I also think that the article confuse…

> Some unit testing frameworks expect their users to use assertions to do the job, others are very much against it because they want to separate between the failures of the system under test from failures of the test. (If that matters, I'm in the later camp). How useful is this distinction in practice? A failing test is going to examined in detail and that examination is going to reveal whether the system under test…

A typical place this distinction is useful is that it determines whether the test-suite runs to completion with multiple tests, or panics/terminates hard on the first failure.

Re: Assert(): A Modern How To

#16

Post by sshine »

foo42 wrote: post #5

An overlapping technique (covering some but not all of the circumstances you'd use assert) is to take a parse-dont-validate approach, and essentially encode the fact that an assertion has been applied to a value in its type. How ergonomic this is will vary by language, but the general idea would be to apply the assertion logic in some sort of constructor, then prevent any operations which would break the invariant go…

It is so nice to come here and want to say something, and someone already said it.

For those who haven't read "Parse, Don't Validate": https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-va...

I'm not sure exactly what languages people think of when they consider asserting, but I presume it's Java, C# or C/C++. In Java asserts are disabled by default, so they're thought of as a debug/development utility.

In another thinkpiece, "It takes two to Contract", it is demonstrated how types and assertions work together in TigerBeetle: https://tigerbeetle.com/blog/2023-12-27-it-takes-two-to-cont...

I think people might be worried of asserting in production because "what if you hit an edge case in production that you haven't accounted for, and the system crashes?" And I either think "You just don't test enough", or "Parse, Don't Validate (rather than assert), report a problem and continue."

> Users of the value who care about the invariant being true can then specify in their types that they want

Now that C# has value types and Java has record classes, this kind of data modelling has become available in mainstream systems languages. I'm not a C++ shark, but I think the closest equivalent is C++20 aggregate structs.

Re: Assert(): A Modern How To

#17

Post by dicroce »

Personally I'm not much of a fan of assert()'s... at least in the language I use the most (C++). It's not that I don't think you should validate the input ranges of parameters to functions its that in general exceptions are better.

Re: Assert(): A Modern How To

#18

Post by klibertp »

johnchinjew wrote: post #8

If we're trying to outline a future for assertions, I think it would help to situate them among the other mechanisms we have for ensuring correctness and explain where assertions have the right tradeoffs. For example, what unique need does a production assertion API satisfy that a normal conditional throw does not? Are there cases where production assertions are still necessary even when invariants are established th…

Asserts are a goto of ensuring correctness. Versatile, powerful, and incredibly easy to misuse.

Whatever correctness goal you're trying to achieve, there are safer, more ergonomic, and stronger alternatives you can reach for: type systems, contract systems, and even normal exception handling are often better. However, if you work in a domain where such tools can't be used or are not available, assert will still be there for you. It's worth knowing how to use it for that situation, but you should favor less ad hoc, more systematic features to ensure correctness in day-to-day programming.

Re: Assert(): A Modern How To

#19

Post by tom_ »

eps wrote: post #10

> Can assertions be used in production? Yes > What should I be asserting on? Invariants > Can I customize how assert behaves? It should abort the program, logging the stack and whatever the context you pass into in, printf-style. If it doesn't abort, it just buries the issue of the program being in incorrect internal state. It should never be OK.

Additionally recommended: if attached to a debugger, the program should stop in the debugger, immediately, without printing a message (you can look at the code), or getting a stack trace (the debugger can do that), or whatever else, to avoid possibly triggering further asserts or causing more problems. This leaves the state just as it was (or as near as feasible), so that it can be investigated.

After being stopped in this way, it must be possible to resume execution somehow. Asserts are code too, and they can be wrong, and it may not be clear why, or what the ramifications might actually be for the specific case - continuing to let the code run can be useful for debugging purposes.

Re: Assert(): A Modern How To

#20

Post by klibertp »

RossBencina wrote: post #2

Interesting article about a worthy topic, even though I disagree with some it. Side note: I expected to see mention of design by contract and function preconditions/invariants/postconditions. I don't think the article is well founded. Before you can discuss usage you need to establish the semantics for assert(). The author touches on this in the introduction but then leaves the details unexamined. In particular I'd n…

> Side note: I expected to see mention of design by contract and function preconditions/invariants/postconditions.

For some reason, DbC seems to be virtually unknown to most programmers. It's incredibly strange: I was sure that DbC would be the next big step after gradual typing. It's just such a natural fit: where the type system gives up (any/dynamic), the contract system can step in. There are papers on automatically generating contracts from types (and vice versa) to allow typed values to flow through untyped code; there are papers showing how to make that performant enough; papers showing how to instrument systems to generate types and contracts from tests; etc. They are all 15-20 years old now, yet there's still nothing suggesting that the mainstream even looks that way, much less actually implements something usable.

Post reply on HN