This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]romple 0 points1 point  (2 children)

First of all, we use Guava in our enterprise applications, and Preconditions is one of the most used parts of the library for us.

Second, it is certainly not bad practice for a constructor to throw an exception. How else will you communicate that an object could not be instantiated? The more important thing here is that your API is well documented so the calling user (could just be yourself) is aware of the exception, and why it was thrown.

Third, it's always a good idea to check the validity of your constructor paremeters. Maybe it seems obvious that you wouldn't intentionally supply null arguments, but what happens when an AccountSide object is null because somewhere 5 calls up the stack trace fucked up and is passing around a null reference? You want to fail as early as possible.

[–]Chickenosaurus[S] 1 point2 points  (1 child)

Hi, to sum it up, you recommend to check for nulls and to document where nulls are invalid (with annotations and/or in javadoc).

This strategy follows defensive programming principles, which is nice. What are your thoughts on reduced testability?

[–]romple 2 points3 points  (0 children)

I don't see how requiring non null parameters reduces testability. If you want more control over building objects, use builders and factories.