OCAJP 7
For example, many of the File methods, such as File.mkdir() return a boolean indicating success. An all-too-common error is for code to call File.mkdir(), ignore the result, and then proceed to work with that directory. If mkdir() fails for some reason, then future code would misbehave. If you're lucky, you'll get an IOException somewhere, but not at mkdir() the failure really occured.
We address this more fully in FIO02-J. Detect and handle file-related errors from our first book.
The best advice I can give ten is: if your method might fail, and the failure might affect anyone who calls your function, then throw an exception. They can catch it if they don't care about failure.
[Java Coding Guidelines] and [The CERT Oracle Secure Coding Standard for Java ] are from the [CERT Secure Coding Initiative]
Stuie Clarky wrote:
I would like to know that if there was a single thing you could get developers to do that would have the greatest impact on improving the level and quality of security, what would it be?
Was there a common recurring factor that kept resurfacing, either during writing the book or that you have seen professionally, that became a real 'bash-head-into-keyboard' moment for you?
You know what I did last summer - Java Coding Guidelines: 75 Recommendations for Reliable and Secure Programs.
If you have ever learnt any Eiffel™, you know that Eiffel™ methods have REQUIRE and ENSURE keywords, to enforce preconditions and postconditions. To use them you have to understand the concepts of class invariants and methods maintaining correctness.David Svoboda wrote:I'd say the biggest thing would be that methods should throw exceptions rather than return error values. . . .
[Java Coding Guidelines] and [The CERT Oracle Secure Coding Standard for Java ] are from the [CERT Secure Coding Initiative]
OCAJP 7
OCAJP 7
OCAJP 7
Don't get me started about those stupid light bulbs. |