New answers tagged

5

There's a problem with 1, 3, and 4: the folder could be deleted between your check and when you try to open it. Or the network could die, or permissions could get in the way, etc. Interacting with the filesystem is a great source of exogenous exceptions. Deciding between 2 and 5, C# style is generally to avoid returning error codes, so I wouldn't recommend ...


1

Java may have just copied this practice from C/C++, where assertions are disabled in an optimized build, as a common practice. The reason for it to be this way in C/C++ is that assert creates additional branch in the code, which is not usually what you want in the release build. The reason it might not matter that much in Java is that JIT will probably ...


4

I think it was a language design choice. Some assertions can be time consuming, especially if they compare the output of some functions. Enabling assertions is like a "debug" flag. Whether that choice is a sensible one is a completely different matter. The way I usually code is that for external/public methods, arguments are checked and ...


8

Assertions are not meant to replace checking method parameters or program state and throwing informative exceptions when facing an exceptional situation. Your program logic or your error handling logic shouldn't rely on them. The purpose an assertion is to force a program to fail when a simple self diagnosis shows there's something wrong with the program ...



Top 50 recent answers are included