tags:

views:

141

answers:

3

Go doesn't provide assertions. They are undeniably convenient, but our experience has been that programmers use them as a crutch to avoid thinking about proper error handling and reporting.

However it has print and println which does

panic like print, aborts execution after printing
panicln like println, aborts execution after printing

Isnt that the same thing as an assert? Why would they claim the above but have panic? i can see it leading to the same problems but adding an error msg to the end of it which can easily be abused. Am i missing something?

+1  A: 

For one, in C, assert() only aborts execution when in debug mode.

Justin Ethier
Yes, and that's a terribly wrong behavior, perhaps the exact one Google wants to prevent. Why would you want to let your program continue running after it's blantantly done something wrong?
zneak
To be exact, assert abort exectution unless the preprocessor NDEBUG macro is defined. It is still possible to have assert outside of debug builds if you so choose.
R Samuel Klatchko
+8  A: 

No, it's not. panic is like "write then abort", while an assert is like "test and if it's false, write then abort". There's no way they can keep you from doing an assert-like statement anyways.

But it's already better than most languages' asserts. At least this won't automatically disappear in production. You shouldn't let your program run if you blatantly know it just did something wrong.

zneak
A: 

I use assert to fail early the program when it discovers via assert that implementation contract is broken. Since the goal of integration is to release valid implementation, assertions used that way help to produce valid programs fast and simply. Failing early in that way is a good thing as it helps released program not to fail late. I agree that adding log message by panic() is helpful but in practice the help is limited as the message won't be logged if integration run its course. Shire number of implementation assertions is such that keeping them all in release will degrade performance, hence they are conditionally compiled. It is also a good thing that author of Go failed in his effort to force developers to implement complete error handling, as this would make 'fail fast and simply' not simple at all. Simplicity of his own language stands in a way. The first thing I will do in writing my Go program is write assert() function that receives bool and string and call panic() if bool is false. I will also make sure that assert() isn't called once integration is complete. All this talk about evil of assertions is like progressive gibberish about benefits of mandatory health insurance. Both will fail for the same reason.

necode