You remind me that I suck at design patterns. IMHO, the patterns are only theoretical, and it doesn’t cover all the details of every language. Sometimes it will be null, empty, or can throw an exception if your team decides that it’s better.

If null is a valid value for the field there is no reason why a builder should not construct an object where the field is null.

The only thing i dislike about the pattern is that a class utilizing the builder to retrieve the object has to know a lot about how the object has to be constructed, however it makes for very readable code imho.

Contrieved examples you usually see in design pattern tutorials do not properly highlight the use case and usefulness of a specific pattern.

What you did might have been fine. You only rarely need the builder design pattern.

It’s useful when the object you want to build has a complex constructor, or several ones, or you want to more easily enforce the self consistency of the created object (some languages make it hard to share initialization code) or you want to hide some internal details (I.e., you are at an API boundary and want to be able to freely change the objects your main object is composed of).

In short, Builder is a way to have a handy interface to an object constructor. It’s nice for users of a library, or if you find yourself repeating a complex constructor invocation often, but you usually do not want to have to maintain such an interface that is, at the end of the day, mostly boilerplate code.