Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

The problem seems to be that assert is implemented as a regular function.

It must be implemented as a macro so that the line number and assertion expressions are printed, allowing to easily identify the failed assertion.

If a language doesn't support such macros and has no ad-hoc mechanism for this case, it should not be used, or if it must the assert function must take a string parameter identifying the assertion.



Some languages allow a stack trace to be obtained in normal code, which enables position reporting without macros. Python and Go are good examples.

If you know the file and line of the assertion, plus the values that are being checked, there's not as much need for a stringified version of the expression.


> If you know the file and line of the assertion, plus the values that are being checked, there's not as much need for a stringified version of the expression.

It does save time. With the actual condition reproduced, half the time I don't even need to check the source of the failed test to know what went bad and where to fix it. Consider the difference between:

  FAILED: Expected 1, got 4
  In /src/foo/ApiTest.cpp:123
vs.

  FAILED: response.status evaluated to 4
          expected: 1
  In /src/foo/ApiTest.cpp:123
vs.

  FAILED: response.status evaluated to Response::invalidArg (4)
          expected: Response::noData (1)
  In /src/foo/ApiTest.cpp:123
This is also why I insist on adding custom matchers and printers in Google Test for C++. Without it, 90% of the time a failed assertion/expectation just prints "binary objects differ" and spews a couple lines of hexadecimal digits. Adding a custom printer or matcher takes little work, but makes all such failures print meaningful information instead, allowing one to just eyeball the problem from test output (useful particularly with CI logs).


Ah, this might be a difference of idiom. I would expect that assertion to print output like this:

  FAILED: Expected RESPONSE_NO_DATA, got RESPONSE_INVALID_ARG
  In /src/foo/ApiTest.cpp:123
For non-enumerated integers, the output would be something like:

  FAILED: Expected ResponseCode(200), got ResponseCode(404)
  In /src/foo/ApiTest.cpp:123
If values are formatted with some amount of self-description, then printing the name of the variable being evaluated is not usually informative.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: