Hacker News Reader

> People prefer to debug a run time stack rather than deal with compile errors

...probably because most popular languages give you compiler errors that sound like "#@#E WTF @#@$ WTF2x @#/&^( WTF3x..." whereas a stack trace is something that one can easily follow and make some sense of even if you are just touching the languge for the first time.

I disagree strongly with exception versus error codes. It sounds reasonable until you look at what real programmers (the kind that isn't perfect) will do and how it affects production code.

Real life programmers don't know the stack up and down and haven't read the documentation for the stuff they use. They will not have thought through every possible error case. Sucks, but that's real life. So any solution that depends on either of those will simply fail. So there's 2 ways to have parts of your program signal errors to other parts. The question that matters is what will mediocre programmers do ?

If you force em to give errors through return codes, they will flat-out ignore the errors. That means errors, and all meta-information about them (like which file it is that won't open, or which host doesn't respond, that sort of thing) disappears into a black hole. It MAY end up in some log file, or it may not. Crucially, sometimes it disappears into a logfile that is custom to the library being used (at least in C). Needless to say, you will have memory leaks when this happens, and you will have invalid state. It may also lead to crashes directly, if it doesn't it will lead to "delayed crashes" (like OOM), and all sorts of fun behavior (which is why some system engineers prefer direct crashes : it makes the point where the problem gets created easy to identify).

If you give them exceptions they will not handle the exceptions, nor will they get try ... finally correct. This will lead to memory leaks and inconsistent data. And it may lead to program crashes, BUT crucially it will preserve the error that was originally detected, and log it in the main program, making fixing the error critical.

Is this "deferred technical debt" ? I can understand your reasoning, but I think checked exceptions are a much, much better solution than return values.

What I find especially irritating is the moronic attitude that testing somehow makes up for not having static types. I have never seen a program that has half the tests any statically typed language automatically executes. Not even once.

Yeah I totally agree here.

There is a lot of hand wringing about hiring 'the best programmers' etc, but the reality is everyone is human and humans make mistake. Lets make the systems resilient to mistakes that humans make - strange how this seemingly simple statement is actually quite controversial around here!

In truly large systems, all of the above happens and more. This is why error handling in C is so problematic, and why we toss it with Java. That go is bringing it back, is a little worrysome. Then again, go might be a hackers language, and might ultimately end up being the repository of write-once programs that aren't maintained.

> What I find especially irritating is the moronic attitude that testing somehow makes up for not having static types.

Or that static types are useless, because "you will need to make unit tests, anyway". As if the static types don't save you from making a lot of unit tests.

But I guess it's useless to wear a seatbelt, because if you crash head-on with semi-trailer you will die, anyway.

> I disagree strongly with exception versus error codes. It sounds reasonable until you look at what real programmers (the kind that isn't perfect) will do and how it affects production code.

I prefer option types or checked exceptions, but mentioned return codes because Go is making them popular again.

The most recent GnuTLS bug comes from an ignored return code:

http://blog.bro.org/2014/03/dissecting-gnutls-bug.html

> There are type system features that ensure a higher degree of correctness, but it's not fun debugging compiler errors when you're trying to get something working.

> For example, being forced to handle errors immediately via return codes or option types is not "fun".

> It is preferable to handle type errors at runtime or through testing instead of at compile time.

Is that right.

Yeah, the wording kind of sucked there. It's better stated as, "Dynamic language users prefer to handle type errors at runtime or through testing instead of at compile time."