I'm a fan of using assertions in the code to check for preconditions. The question is whether is it wise to use assertions in public methods to check the precondition?My personal opinion is, that if my method can not handle the absence of a parameter (or some invalid value of it) and it is part of an API but does not rely on user input, then the issue (bad parameter) must be handled during the development process (at least by the integration tests) and not later when the software is used on field. For this reason I do use assertions even in public methods.I mean something like this:public class SomeMagic implements MagicAPI {    public WoW doSomeMagic( Stuff source ) {        assert source != null : Incorrect use of the API;        // if assertions are deactivated (should be the case in production environment)        // this line will throw a NpEx         if ( source.isPlainStuff() ) {            // some magic with a plain stuff        }        return Wow.beSurprised;    }}
Asserting in public methods
java;assertions
It's context sensitive. I once tried to create a guideline when to use assertions vs error handling. I called it a degree of trust trade-off and illustrated like this:!!!!!!!!!!!!!    a) user input...!!!!!!!!!!    b) external data input (network, ...) ......!!!!!!!    c) internal data input (other process)*.........!!!    d) library (external)**..........!    e) library (internal)****.........    f) public functions (team)********.....    g) public functions (own code)************.    h) private functions! extra validation needed (anything can be thrown in), never ever any assumptions!. standard validation* assertions only possibleIn your case (internal library API?) I would tend to validate more than use assertions. It's very difficult to anticipate all (ab)uses of library by caller code and integration testing coverage tends to be patchy. If there's no limitation you can also leave assertions in the production code to keep validation (they would turn into exception).