Seriously considering enforcing every assertion of the form,
String objectA = objectB.getStringValue();
Rewrite as the following,
String objectA = objectB.getStringValue() != null : objectB.getStringValue() ? "";
Advantage, you won't encounter a NullPointerException.
Disadvantage, every object has to have a default, non-null state.
Anyhow, this is not a recommended practice. In many cases, all a programmer would be doing is replacing poor code which throws a NullPointerException with poor code that will try to work with bad data (and eventually choke with unclear symptoms).
A better rule of thumb might be, if your writing a producer, never return a null object, throw an exception instead as an expression of error. If the value is a null reflecting the storage (file/relational db or something else), then it cannot be helped.
If your writing a consumer, always check your arguments, log which ones are null and re-throw a runtime exception. Unfortunately, a runtime exception can throw things out of whack. Use it judicously. If a null object can exist (see the storage case above), you may have to work around it (by applying a default code path). Even if you were to assert that the consumers arguments cannot be null, a code review would catch it, since your assertions are now explicit.
To conclude, I recommend that a consumer must avoid re-throwing a runtime exception, check its arguments, and wherever possible, explore the option of providing a default code path when critical arguments to the consumer are null. For example, if a users language and country is null, select the system default locale.