I find assertions really usefull for examples in documentation and sometimes in code for devs (by far better than comments). http://c2.com/cgi/wiki?DoNotUseAssertions
2016-04-22 8:45 GMT+02:00 Lyndon White <[email protected]>: > > *TL;DR; Assert is no slower than exception throwing& the problem is > people expect it to be a `nop` if optimisation is turned on. and a `nop` is > much faster than an assert*(*I haven't actually tested this), > > > Its not that assert is slow. > it is that traditionally (and we are talking going back to a very long > time), > `assert` statements are removed by the optimizer. (Eg. It is one of the > only things done by `cpython -o`) > Because `asserts` are error messages targeted at the developer. > In theory they will never be triggered at run time, in "shipped" code. > > This is different from Exceptions. > Exceptions may be thrown (and not caught) in shipped code. > Its bad, but sometimes unavoidable, > and it is better that the exception is thrown (and not caught) than to > allow the program to run in an unknown state (potentially leading to data > corruption, or infinate looping or all kinds of problems). > > vs if the exception was instead an assert, then in the shipped version > they are not their and so the program runs in unknown state. > > Currently running `julia --optimise` does not actually remove them. > This is generally considered a bad thing. > It break the expectation that they will be gone in the optimised version. > This is very bad, if you have an `assert` in a key inner loop. > > > > However, some people are writing code, that is using asserts to check that > a function is being used correctly. > Because they are lazy (aren't we all? I know I do this). > If this code is ship in optimized form (without asserts), then the users > of there code (if it is a library) are going to be be able to get into > unintended states -- by accident. > > Now what people should do, is as in your example check conditions and > throw meaning full exceptions. > Your way works, as does using an if statement (i'ld use an if statement, > but that is just me). > But as a hack for those of us who are lazy, a @check macro was proposed, > which would not be removed by the optimizer. > > > > >
