crash in cursor.js

[ippa]

I'm trying out the simplest code possible and it's resulting in a crash. My testscript is here http://pastie.org/1745380 ... + the my node-version and the output when the script crashes.

The database/collection does indeed exist, from mongo console:

db.screens.find().length() 1

[marcello3d]

The cause of the bug is the lack of callback passed to findOne. This should throw a different exception, so there's definitely a bug in Mongolian DB to be fixed.

However, there's a deeper question here: what is your use-case for calling findOne without a callback? Should it be allowed or just give a better error message?

[ippa]

Sorry, you're right:

screens.findOne( function(err, screen) { console.log(screen) });

does work good, though bellow code just prints "undefined", how come?

screens.find().forEach( function(err, screen) { console.log(screen) });

[ippa]

about me calling findOne without a callback was just to get the crash. But since you ask, would it be possible to have blocking and nonblocking functionallity in the same lib?

If no callback is given it will block just as in mongo console. Simpler blocking methods has it's usecases too.

screens.findOne(); --> returns: the first object

screens.findOne( function(err, screen) { .. bla bla async results } )

[ippa]

Digged through the source, seems like it's the example in the README that is wrong:

This worked for me:

screens.find().forEach( function(screen) { console.log(screen) });

.. readme gives an example of .forEach( function(err, screen) {} ) though

[marcello3d]

You're correct. I should update the Readme. This changed in 0.1.5. You will want to use a second callback to handle errors and completion of the forEach loop.

As for synchronous returns, there is no way I'm aware of to do that in node.js, because all the mongodb networking is asynchronous.

[marcello3d]

the original error should be fixed by d36d26954333a0e4f397f002ad643210ff32ae5b