Reputation
2,961
Top tag
Next privilege 3,000 Rep.
Cast close & reopen votes
Badges
15 30
Newest
 Good Answer
Impact
~150k people reached

14h
comment Swift: Creating an empty array
@S.Eberl No, the type is "array of String". I've never written Swift, but I doubt it has a type "empty array". So you're creating an object of type "array of String" which happens to be empty. The emptiness itself isn't part of the type.
20h
comment Best way to handle nulls in Java?
@Woot4Moo Your API must never try to silence errors in the client's code. You are doing them a disservice. On the contrary, the API must bring errors to the caller's attention, which in turn will help them correct their own code. Consider this alternate scenario: division by zero is always an error. What would happen if your code silently corrected a 0 to a 1 in order to save the caller the effort of dealing with a division by zero error? Hiding caller errors under the rug is almost never the right course of action.
20h
comment Best way to handle nulls in Java?
@Woot4Moo No, that's the wrong approach. You are silently correcting an NPE because you are letting the caller indistinctly use "" or null, which is almost never the right course of action. If you do this, you should also write in your javadoc "be aware the API treats "" and null indistinctly", at which point you must just as well simply write "null is an error" and throw an exception. Clients calling your code will become aware of the problem the first time they try using a null, so what's the big deal. And if they are accidentally passing null, then it's an ERROR in THEIR CODE.
20h
comment Best way to handle nulls in Java?
@Woot4Moo So write your own code that throws an exception then. The important thing is to inform the caller that their passed arguments are wrong, and tell them as soon as possible. Silently correcting nulls is the worst possible option, worse than throwing an NPE.
21h
comment Best way to handle nulls in Java?
In my opinion it makes more sense to place an assert and throw an exception if the argument is null, since it's clearly the caller's mistake. Don't silently "fix" caller mistakes; instead, make them aware of them.
22h
comment Is it okay to return the “wrong” HTTP status code in order to show a more user-friendly error page?
@jwenting It seems to me you'd be subverting the intended meaning of HTTP codes. In an extreme case, you can always return a 200 and a text describing the error, but that would against the spirit of HTTP, wouldn't it? What kind of information would a 404 be leaking to an intruder, anyway? (I understand the case against a 403, though).
1d
comment Is it okay to return the “wrong” HTTP status code in order to show a more user-friendly error page?
@jwenting Are you proposing subverting HTTP in exchange for (allegedly) increasing security? The same argument can be used like this: "don't follow any internet standards, because standards can be exploited by attackers."
2d
comment Unexpected IndexOutOfBoundsException
I took the liberty of improving this answer by pointing out there is a bug in the OP's code, which results in the out of bounds exception.
2d
revised Unexpected IndexOutOfBoundsException
added explanation of bug in OP's code
2d
revised Unexpected IndexOutOfBoundsException
changed title to correspond to actual question
Aug
28
comment Is there empirical evidence supporting Brook's Law (or a modification of it)?
@Mandrill I find it curious that nobody made the effort to research this, since it's one of the fundamental insights of software engineering. Anecdotes remain just that -- anecdotes. Research work that documented hundreds or thousands of cases where this purported law holds would go a long way. Research is very important for software engineering, otherwise we will remain in an age of cargo cult methodologies and processes :/
Aug
26
reviewed Approve Using private vs company devices for development at work
Aug
17
awarded  Good Answer
Aug
7
comment Are data type declarators like “int” and “char” stored in RAM when a C program executes?
I think this answer isn't helpful. It complicates things way beyond the current level of understanding of the OP. It's clear the OP doesn't understand the basic execution model of a CPU + RAM, and how a compiler translates symbolic high-level source to an executable binary. Tagged memory, RTTI, Lisp, etc, is way beyond what the asker needs to know in my opinion, and will only confuse him/her more.
Aug
7
comment Are data type declarators like “int” and “char” stored in RAM when a C program executes?
@user16307 Try not to worry about C++ and C#. What these people are saying is way above your current understanding of how computers and compilers work. For the purposes of what you're trying to understand, the hardware does NOT know anything about types, char or int or whatever. When you told the compiler some variable was an int, it generated executable code to handle a memory location AS IF it were an int. The memory location itself contains no info about types; it's just that your program decided to treat it as an int. Forget everything else you heard about runtime type information.
Aug
6
comment Are data type declarators like “int” and “char” stored in RAM when a C program executes?
@vaxquis Jorg's answer is pretty good as well, and has my +1.
Aug
6
comment Are data type declarators like “int” and “char” stored in RAM when a C program executes?
@vaxquis I'd argue that the computer doesn't know. The compilers for C++, Java, etc. produce additional code to handle this information -- which again, I think it's a more advanced topic than what the OP is asking about -- but the hardware knows nothing of it. You have to keep track of this because the computer doesn't know how to do it; C++ (for example) merely generates code for this, so that you don't have to write it yourself. Compare this to writing assembly code. This is why I consider Ryan's answer the best for the kind of knowledge level I assume the OP to have.
Aug
6
comment Are data type declarators like “int” and “char” stored in RAM when a C program executes?
@vaxquis I don't think the OP is asking about the sort of things RTTI addresses. The OP is asking something way more basic: how does a computer "know" whether the contents of a register or a memory location is an int, or a char, or whatnot. And the answer is "the computer doesn't, but the compiler will generate code that treats the stored value differently according to the type at compile time."
Aug
6
comment Is type safety worth the trade-offs?
@MasonWheeler Agreed, that blog post is embarrassingly bad. The conclusions are also awful ("Java claims to be static, but it does this which isn't static, therefore static typing is no good"). Maybe there are better arguments out there, but this blog isn't one.
Aug
6
comment Is type safety worth the trade-offs?
The paper: Haskell vs ..., An Experiment in Software Prototyping Productivity - Paul Hudak and Mark P. Jones. It describes the results of an experiment ordered by ARPA and the US Navy.