12 ms·

These days I actually cannot recall when that happened to me the last time, hence my curiosity. I remember null pointer dereferences in C++ on Android being imp

by ygra 10y ago

These days I actually cannot recall when that happened to me the last time, hence my curiosity. I remember null pointer dereferences in C++ on Android being impossible to debug, but honestly cannot recall the same for C# in VS. Might be that we simply don't write code that's susceptible to that problem (writing libraries ideas of applications makes you kinda defensive sometimes), or maybe that our code is often a bit conservative out of necessity, so no C# 6 features yet (others have pointed out that certain constructs are prone to let you guess on which line it happened).

tracker1 10y ago
It's funny, but with JS I write pretty defensively to prevent null references... function frob(foo) { return (foo && foo.ary || []) .map(...) } Even though I know everything that will call frob exists and has ary, that doesn't mean it won't change or work otherwise... one of the things I like about how shorting works in JS... though the "?" conditional null thing in C# is pretty damned close.
- lmm 10y ago
  That ends up worse than null because the actual error will happen even further away when some value is surprisingly []. You want to fail fast in cases where your state no longer makes sense. (This is why naive use of options can end up worse than null).
  - tracker1 10y ago
    If the function ALWAYS returns an array, then so be it. If someone's response to my function can't handle an empty array, then their method probably has other issues, and they should check their own data before calling into it. I'll do other methods that will return an appropriate value, or null. In this way, if you can be defensive in your own code, you aren't the one called when someone hands you garbage. Just like an HTTP server shouldn't crash because someone sends it data that should return a 4xx response.
    - lmm 10y ago
      > If the function ALWAYS returns an array, then so be it. If someone's response to my function can't handle an empty array, then their method probably has other issues, and they should check their own data before calling into it. It's best to make it impossible to call your function with the wrong kind of thing, but Javascript doesn't have a type system. Still though, if their code has gotten into a nonsense state, better to throw an exception (or whatever the language-standard way of handling errors is) than silently carry on. Otherwise they can spend up hours debugging their filtering logic wondering why it's started filtering everything out, when in fact the server they were calling into has started sending 1-element responses as not an array which your code then silently changes into an empty array. > I'll do other methods that will return an appropriate value, or null. In this way, if you can be defensive in your own code, you aren't the one called when someone hands you garbage. If you propagate garbage you're part of the problem. Defensiveness goes hand-in-hand with fail-fast. > Just like an HTTP server shouldn't crash because someone sends it data that should return a 4xx response. Right but if your query was malformed you should get a 4xx, not a 200 with no results. (This is one reason I think it's actually a bad idea to use 404 for when there's no item with that ID - it makes it hard for the client to tell the difference between "I called the API wrong" and "I called the API correctly but there are no results").

by ygra 10y ago

tracker1 10y ago

It's funny, but with JS I write pretty defensively to prevent null references... function frob(foo) { return (foo && foo.ary || []) .map(...) } Even though I know everything that will call frob exists and has ary, that doesn't mean it won't change or work otherwise... one of the things I like about how shorting works in JS... though the "?" conditional null thing in C# is pretty damned close.

lmm 10y ago
That ends up worse than null because the actual error will happen even further away when some value is surprisingly []. You want to fail fast in cases where your state no longer makes sense. (This is why naive use of options can end up worse than null).
- tracker1 10y ago
  If the function ALWAYS returns an array, then so be it. If someone's response to my function can't handle an empty array, then their method probably has other issues, and they should check their own data before calling into it. I'll do other methods that will return an appropriate value, or null. In this way, if you can be defensive in your own code, you aren't the one called when someone hands you garbage. Just like an HTTP server shouldn't crash because someone sends it data that should return a 4xx response.
  - lmm 10y ago
    > If the function ALWAYS returns an array, then so be it. If someone's response to my function can't handle an empty array, then their method probably has other issues, and they should check their own data before calling into it. It's best to make it impossible to call your function with the wrong kind of thing, but Javascript doesn't have a type system. Still though, if their code has gotten into a nonsense state, better to throw an exception (or whatever the language-standard way of handling errors is) than silently carry on. Otherwise they can spend up hours debugging their filtering logic wondering why it's started filtering everything out, when in fact the server they were calling into has started sending 1-element responses as not an array which your code then silently changes into an empty array. > I'll do other methods that will return an appropriate value, or null. In this way, if you can be defensive in your own code, you aren't the one called when someone hands you garbage. If you propagate garbage you're part of the problem. Defensiveness goes hand-in-hand with fail-fast. > Just like an HTTP server shouldn't crash because someone sends it data that should return a 4xx response. Right but if your query was malformed you should get a 4xx, not a 200 with no results. (This is one reason I think it's actually a bad idea to use 404 for when there's no item with that ID - it makes it hard for the client to tell the difference between "I called the API wrong" and "I called the API correctly but there are no results").