5 ms·

I've made my peace with null. Null is basically just an implicit assert(valid(x)) before every time you call a method on x. Similary, I think of exception

I've made my peace with null. Null is basically just an implicit assert(valid(x)) before every time you call a method on x. Similary, I think of exceptions as explicit "crash-unless-caught" commands. If you write your program with the "blow up early" mentality anway, or use static checking tools and a bit of discipline, I've found that null looses it's terror.

pjmlp 8y ago
That is a very big IF, considering how many teams are actually structured.
lawn 8y ago
Oh I'm fairly disciplined. But we use a 15 year old code base which should've been made with more discipline than it was. Additionally the program shouldn't "blow up early" but it was in many ways coded that way.
gre 8y ago
“Looses its terror” here means the opposite of “loses its terror”.
- piyh 8y ago
  Cry havoc and let loose the null pointer exceptions
kzrdude 8y ago
If it's C, it's far more terrifying than that.. there is no assertion! just a vauge threat that something will go wrong if you stick a null in there, with no guarantees and no checks.
deleted 8y ago
[deleted]
lmm 8y ago
Sure, null can be a non-problem for the low, low price of 3 or 4 extra lines on each function. But those extra lines distort your program architecture, pulling you away (perhaps without even noticing) from short, composable functions.
arcticbull 8y ago
In market terms, sir, you've entered the capitulation phase haha. It's actually not correct to say that accessing null will always blow up. In embedded systems without memory protection address 0 may well contain valid data, usually a vector table. In WASM address 0 is totally valid also, if I'm not mistaken, as memory is represented as a big ol' array with an offset and checking for 0 would be too inefficient.
masklinn 8y ago
> I've made my peace with null. Null is basically just an implicit That very much depends on the language: 1. it can be a compile-time error (Swift) 2. it can be a runtime error (java, C#) 3. it can depend on what you're actually using (Python, Ruby, and on runtime extensions you might have loaded in the latter case) 4. it can be a no-op (objective-c) 5. it can depend on the combination of platform, compiler and surrounding code going from a segfault to deleting your program's security and/or causality (C, C++) 6. it can depend on the implementation and exact codepaths (Go) etc...

pjmlp 8y ago

That is a very big IF, considering how many teams are actually structured.

lawn 8y ago

Oh I'm fairly disciplined. But we use a 15 year old code base which should've been made with more discipline than it was. Additionally the program shouldn't "blow up early" but it was in many ways coded that way.

gre 8y ago

“Looses its terror” here means the opposite of “loses its terror”.

piyh 8y ago
Cry havoc and let loose the null pointer exceptions

kzrdude 8y ago

If it's C, it's far more terrifying than that.. there is no assertion! just a vauge threat that something will go wrong if you stick a null in there, with no guarantees and no checks.

deleted 8y ago

[deleted]

lmm 8y ago

Sure, null can be a non-problem for the low, low price of 3 or 4 extra lines on each function. But those extra lines distort your program architecture, pulling you away (perhaps without even noticing) from short, composable functions.

arcticbull 8y ago

In market terms, sir, you've entered the capitulation phase haha. It's actually not correct to say that accessing null will always blow up. In embedded systems without memory protection address 0 may well contain valid data, usually a vector table. In WASM address 0 is totally valid also, if I'm not mistaken, as memory is represented as a big ol' array with an offset and checking for 0 would be too inefficient.

masklinn 8y ago

> I've made my peace with null. Null is basically just an implicit That very much depends on the language: 1. it can be a compile-time error (Swift) 2. it can be a runtime error (java, C#) 3. it can depend on what you're actually using (Python, Ruby, and on runtime extensions you might have loaded in the latter case) 4. it can be a no-op (objective-c) 5. it can depend on the combination of platform, compiler and surrounding code going from a segfault to deleting your program's security and/or causality (C, C++) 6. it can depend on the implementation and exact codepaths (Go) etc...