Content deleted Content added
Citation bot (talk | contribs) Add: title. Changed bare reference to CS1/2. | Use this bot. Report bugs. | Suggested by BrownHairedGirl | Linked from User:BrownHairedGirl/Articles_with_bare_links | #UCB_webform_linked 503/2198 |
→Disabling assertions: Add Python, copy-edit Java segment. |
||
Line 122:
Most languages allow assertions to be enabled or disabled globally, and sometimes independently. Assertions are often enabled during development and disabled during final testing and on release to the customer. Not checking assertions avoids the cost of evaluating the assertions while (assuming the assertions are free of [[Side-effect (computer science)|side effects]]) still producing the same result under normal conditions. Under abnormal conditions, disabling assertion checking can mean that a program that would have aborted will continue to run. This is sometimes preferable.
Some languages, including [[C (programming language)|C]] and [[C++]], can completely remove assertions at compile time using the [[preprocessor]].
Similarly, launching the Python interpreter with "-O" (for "optimize") as an argument will cause the Python code generator to not emit any bytecode for asserts.<ref>[https://docs.python.org/3/reference/simple_stmts.html#grammar-token-assert-stmt Official Python Docs, ''assert statement'']</ref>
Java requires an option to be passed to the run-time engine in order to ''enable'' assertions. Absent the option, assertions are bypassed, but they always remain in the code unless optimised away by a JIT compiler at run-time or [[dead_code_elimination|excluded at compile time]] via the programmer manually placing each assertion behind an <code>if (false)</code> clause.
Programmers can build checks into their code that are always active by bypassing or manipulating the language's normal assertion-checking mechanisms.
| |||