Timeline for Assertion statements: Remove or retain in production code
Current License: CC BY-SA 4.0
14 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Apr 21, 2022 at 12:22 | history | edited | Doc Brown | CC BY-SA 4.0 | edited body |
| Sep 24, 2021 at 20:07 | history | edited | Deduplicator | CC BY-SA 4.0 | copy-edited |
| S Sep 24, 2021 at 18:20 | history | edited | lennon310 | CC BY-SA 4.0 | Punctuation & capitalisation |
| S Sep 24, 2021 at 18:20 | history | suggested | Alex Waygood | CC BY-SA 4.0 | Punctuation & capitalisation |
| Sep 24, 2021 at 18:05 | review | Suggested edits | |||
| S Sep 24, 2021 at 18:20 | |||||
| Sep 23, 2021 at 8:31 | history | edited | Doc Brown | CC BY-SA 4.0 | Paragraph at the end added |
| Sep 23, 2021 at 8:25 | history | edited | Doc Brown | CC BY-SA 4.0 | Paragraph at the end added |
| Sep 23, 2021 at 8:12 | comment | added | Doc Brown | @Green: such a check is unlikely to make the program behave differently when deactivated, of course, and it may increase readability, not decrease it. However, you still have to answer to yourself if there is a risk that problem could arise in production - which is really context dependent. If yes, a line if (a.size()!=b.size) throw new IllegalStateException("Internal program error in function foo") could be more appropriate. Not i am not advocating this - this one could also be a perfect match for an assertion. | |
| Sep 23, 2021 at 8:05 | history | edited | Doc Brown | CC BY-SA 4.0 | added 13 characters in body |
| Sep 23, 2021 at 8:00 | comment | added | Green 绿色 | However, if one of or both those lists only live within a single method, unit tests won't be able to cover this constraint. | |
| Sep 23, 2021 at 7:58 | vote | accept | Green 绿色 | ||
| Sep 23, 2021 at 7:30 | comment | added | keuleJ | @Green maybe the assertion you just mentioned would be better part of a unit test | |
| Sep 23, 2021 at 7:20 | comment | added | Green 绿色 | An example: I have a list of objects and a list of integers. According to the code logic, the two lists should have the exact same number of elements because there is some connection between them (e.g., the integers are indices of the objects in a previous list). In this case, I used assert a.size() == b.size after their construction. It not only serves as check while developing and testing the code, but also as documentation for colleagues who later might modify it. What alternative would be appropriate in this case? | |
| Sep 23, 2021 at 6:54 | history | answered | Doc Brown | CC BY-SA 4.0 |