New answers tagged

0

Programming is about work I think the easiest way to answer this is to understand the progress OOP has made over the years. Everything done in OOP (and most programming paradigms, for that matter) is modeled around needing work done. Every time a method is called, the caller is saying "I don't know how to do this work, but you do know how, so you do it ...


1

Suppressing warning for an entire method is suspect. Better to suppress the warnings for the specific line, with a comment. e.g. @SuppressWarnings("unchecked") Foo foo = (Foo)object; // Using old library requires this cast


10

Suppressing warnings is something that needs to be done with extreme care. A warning means: The compiler found something that looks dodgy. It doesn't mean it is dodgy, it just looks like it to the compiler. Sometimes you have code that is perfectly fine and gives a warning. Sometimes you fix it by slightly modifying your code. Sometimes the compiler has ...


11

To me, the entire point of suppressing warnings is to maintain a "clean bill of health" for your project. If you know that your entire code base compiles cleanly, it's immediately obvious when someone does something wrong that causes the first warning to appear in the issues list. You can then fix the error or suppress it if you can prove that it's spurious. ...


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 ...


1

You "only" need a separate exception type if you want to handle it separately. IFF you want to catch a certain exception type separately from other errors, then creating a dedicated type for it (no matter from what it is derived) is the best option IMHO. That being said, I think this is a rather big if for most cases. Especially the ...


1

I would need to inspect the message to see which argument was out of range, and then prompt the user. While this isn't exactly BAD It's certainly a code smell from my PoV. Leaving aside whether you want to handle longitude and latitude errors differently, I would certainly consider one of the following options: a new subclass for each error. In this ...


2

In my opinion, exceptions are an essential tool for detecting code errors at run time. Both in tests and in production. Make their messages verbose enough so in combination with a stack trace you can figure out what happened from a log. Exceptions are mostly a development tool and a way to get reasonable error reports from production in unexpected cases. ...



Top 50 recent answers are included