3 ms·

Most frameworks give 400 bad inputs. If the client gives a null but null is not allowed in the type, it will auto respond with 400 before it ever invoked the ha

Most frameworks give 400 bad inputs. If the client gives a null but null is not allowed in the type, it will auto respond with 400 before it ever invoked the handler. Java spring does the same thing: if you use an unboxed type (int instead of Integer) and the client passes in null, the handler will never be invoked.

taeric 4y ago
But if you have an evolving API, you are back to what was asked. Either you are a bit of a jerk to all of your existing clients, or you have default values at the boundary. I've found myself with this a lot on "progress" data classes where I will be building up a set of data over several expensive calls. I /could/ make a new type per current state of that, such that I never have nulls. I /could/ make it so that every field is Optional. Or, I could work on a convention that fields are filled out in order, and after the first null, nothing is available. In many years, this has not been where null pointers hit me.
- treis 4y ago
  To add to this I had a specific scenario in mind. At @current_job they bolted on a immutable struct library and wrote validations. We are responsible for sending out renewal notices and we get the renewal price from another system. In certain scenarios we were getting back a null price and our validations dutifully caught the null and threw an exception. Theoretically everything worked. However, the end result is (1) the customer didn't get their renewal notice and (2) we got a validation error instead of (maybe) a NPE somewhere. So what exactly are we accomplishing here is my broader point.
  - anthlax 4y ago
    To be honest, this is more of a question about how best to handle errors in asynchronous event handlers (not handlers marked as async, I mean like send an email at xyz time). Imo best way to solve this is to get notified of an error in sentry, be it an NPE or validation error. In a case where the client expects an immediate response (http GET) getting “400 validation error: foo is not allowed to be null” is a lot more meaningful than “500 Null pointer”. In general I try not to model invalid states - less mental overhead (no one has to tell you xyz can’t be null it just cannot be null). Ofc this is a matter of opinion and the lines get blurred as soon ad you move stuff to runtime.

taeric 4y ago

But if you have an evolving API, you are back to what was asked. Either you are a bit of a jerk to all of your existing clients, or you have default values at the boundary. I've found myself with this a lot on "progress" data classes where I will be building up a set of data over several expensive calls. I /could/ make a new type per current state of that, such that I never have nulls. I /could/ make it so that every field is Optional. Or, I could work on a convention that fields are filled out in order, and after the first null, nothing is available. In many years, this has not been where null pointers hit me.

treis 4y ago
To add to this I had a specific scenario in mind. At @current_job they bolted on a immutable struct library and wrote validations. We are responsible for sending out renewal notices and we get the renewal price from another system. In certain scenarios we were getting back a null price and our validations dutifully caught the null and threw an exception. Theoretically everything worked. However, the end result is (1) the customer didn't get their renewal notice and (2) we got a validation error instead of (maybe) a NPE somewhere. So what exactly are we accomplishing here is my broader point.
- anthlax 4y ago
  To be honest, this is more of a question about how best to handle errors in asynchronous event handlers (not handlers marked as async, I mean like send an email at xyz time). Imo best way to solve this is to get notified of an error in sentry, be it an NPE or validation error. In a case where the client expects an immediate response (http GET) getting “400 validation error: foo is not allowed to be null” is a lot more meaningful than “500 Null pointer”. In general I try not to model invalid states - less mental overhead (no one has to tell you xyz can’t be null it just cannot be null). Ofc this is a matter of opinion and the lines get blurred as soon ad you move stuff to runtime.