• she/her

Principal engineer at Mercury. I've authored the Dhall configuration language, the Haskell for all blog, and countless packages and keynote presentations.

I'm a midwife to the hidden beauty in everything.

๐Ÿ’– @wiredaemon


discord
Gabriella439
discord server
discord.gg/XS5ZDZ8nnp
location
bay area
private page
cohost.org/newmoon

wiredaemon
@wiredaemon

I sometimes see code that is self sabotaging:

public static int getSize(int[] array){
    if(array==null) throw new IllegalArgumentException("oh no, you passed null!");
...
}

I find that so incredibly difficult to comprehend. Why would you not just return 0? I'm being serious. I sometimes read code that goes out of its way to not work in the exact scenarios the people that supply that code don't want their code to be used. I don't think I have ever heard a good reason to do that. Like, yeah, you shouldn't depend on the interna of an implementation, but actively making your code less functional only so no one can depened on them?


fullmoon
@fullmoon

another thing along these lines that bothers me is: command line tools that fail when you give them 0 arguments


You must log in to comment.

in reply to @wiredaemon's post:

i very well could write this code

null as a sentinel value is used for different things in different contexts (this variable is uninitialized, this parameter should get the default value, the user neglected to supply this value). i don't want to assume how my callsite is treating null, so it's not safe to assume that size(null) == 0 makes sense for them

plus, a lot of the time a null value signals a mistake. if i'm going to make any assumption, the most conservative is probably to assume that null is wrong

Hmm I actually disagree.
In a dynamically typed language, where you might want your code to be a bit more resilient, I can see the case for getSize(null) = 0, but in Java, null is not a valid array and if getSize is ever passed a null, that is a bug and I want it to fail as quickly as possible.
Ideally, this would be caught at compile time of course, but if that is not an option, I would 9 times out of 10 still take the function that crashes immediately over the one that produces a wrong result and breaks something else later on.