>> In Java, accessing a null pointer would throw an exception, which (if
>> nothing else) will dump a stack trace to stderr.
>
>    But [...]  you might end up in a situation where
> the stack trace is completely unhelpful and you have no idea whatsoever
> where that null pointer is coming from in your code.

Yes. I hate it when that happens. While accessing a pointer without 
checking whether it's null is arguably a bug, knowing where this happens 
often tells you nothing about how the heck the pointer came to *be* null 
in the first place - and /that/ is usually the real bug.

I gather people use step debuggers and the like to hunt down such 
things. Let's just hope the null pointer isn't because of some cruel 
concurrent thread interaction. (There's a /reason/ why most people avoid 
concurrency.)

>> In Haskell, accessing a null pointer would... be quite impressive,
>> actually. Given that the core language itself has no notion of "pointer"
>> nor what it means to be "null".
>
>    Well, I did say "or some other similar error".

Sure. I was just pointing out that an entire class of very nasty bugs 
completely fails to exist, and hence never needs to be debugged. Which 
is a big win. However...

>> Probably the closest equivalent is the "head []" error.

...it's not the solution to everything.

>> Yes, there /is/ a debugger. No, it will /not/ give you a stack trace.
>
>    So how is that problem usually solved? "Just review the entirety of your
> code and try to find the bug"?

It would be nice if that wasn't the actual answer, wouldn't it?

I should point out that the error message is actually telling you what 
function threw an exception. In this case, the "head" function threw an 
exception because it was given an empty list as input. So you only need 
to look at places in your code that call "head".

Good coding practise dictates that if you call "head", you should check 
the list isn't empty first, and throw your own more-specific exception 
if the list /is/ empty somehow. (E.g., if a dictionary lookup uses a 
list internally somehow, it should throw an exception like "lookup: key 
not found" rather than just "head []".)

Still, this is one of the more frustrating things about Haskell. It's 
somewhat offset by the fact that we have a REPL, and you really can run 
most pure functions without having to initialise a whole bunch of stuff 
in a certain order. (I.e., you /can/ easily test isolated functions.) 
Even so...

Post a reply to this message