Enable by default instead.

[borissmidt]

I seem to often forget to enable the assert flag when i run the tests of a project and also when building a development app.

It might be a better idea to by default enable the assertions and make the release/unsafe build explicit since a real release often already is a special build in many cases.

But using assertions + panics really cleans up many of the undefined behavior and unhandled cases make the code clearer instead of having a lot of 'implicit' behavior.

[negrel]

Ok I will consider it for the next release.

In the mean time, I recommend you to define the GOFLAGS env var to -tags assert so you don't have to specify it manually.

[borissmidt]

Ah great idea!

[negrel]

Hey, I released a new version based on testify v1.10.0 and removed useless dependencies. Though I didn't change the conditional compilation flag.

I'm leaving this issue open for now so people expecting / prefering behavior you described can like your comment.

[m-ocean-it]

I actually, prefer it the way it is now. If someone is currently adding it to some project in the organization, there's a chance they will forget about build tags altogether. This could lead to unwanted crashes in production.

[YoungMind1]

I actually, prefer it the way it is now. If someone is currently adding it to some project in the organization, there's a chance they will forget about build tags altogether. This could lead to unwanted crashes in production.

Adding 'asserts' to a project should lead to crashes if bugs happen, that is just the nature of it. crashing is far more preferable than unknown state of the application.

[m-ocean-it]

crashing is far more preferable than unknown state of the application.

Depends. If an unknown state presents only within some small proportion of, say, calls to some non-critical API method, then not crashing the whole app would likely be preferable.

There are stories of people deciding to add assertions to their project just to be punished later for creating an incident in production.

[m-ocean-it]

And, also, what's the point of this package for you, then? You can fork it and remove conditional compilation.

[borissmidt]

The point is that you catch programming errors so instead of getting a NPE exception you can assert them on object creation. Then a lot of other validation can be added like 'tiger beetle' so you are sure that in dev everything works fine.

At 'tigerbeetle' they run simulations of errors and whenever the program crashes because of an assert it means that some of the 'assumptions' by one part of the code doesn't match assumptions of the other part.

This allows you to get away with a lot less unit tests and faster test cycles because most failures are simulated.

The thing is if the assertions are off by default it will be forgotten to be enabled and it reduces the amount of 'bugs' catched. It also makes the unit testing aspect harder since in that case you are flying without asserts.

So instead a 'release' build could be used where assertions are then disabled. But it might be a better idea to be able to enable/disable depending on the packages. Then when a performance issue is detected because of an assert it can be specifically disabled.

Depends. If an unknown state presents only within some small proportion of, say, calls to some non-critical API method, then not crashing the whole app would likely be preferable.

So for non critical API calls the asserts should have caught it in dev and not in prod. I also question if it is a non critical API then it shouldn't need assertions in the first place. A tool like Tigerbeetle seems to value correctness a lot because it includes money. So mistakes are not allowed to happen. With other services asserts can be overkill and you can still catch the panic at the call site in your http returns.