Node.js: Break on Uncaught Exceptions

In the event the implemented error handling isn’t what it’s all cracked up to be, having the Node.js debugger break on uncaught exceptions is quite simple:

Assume the following code, where bogus  is undefined:

Line 3 will terminate the application (normally), and log an exception in stdout (or the console, a log, etc.) — even when Node.js is in debug mode.

To debug this uncaught exception JIT, the implementation may be as follows:

Run the above application (whose filename is “index.js”) as node --debug index.js  and after 2 seconds (notice the timeout) the exception will be uncaught, but the process will break on line 5 for debugging.

See this gist for an auxiliary and shortened reference.

Node.js: Dynamic Event Listener Binding and Removal

Read this SO question first: Removing event listener which was added with bind

Now that we’re on the same page. I’m going to make this short’n’sweet by providing a premise and letting the code do the talking: The example provided in the SO post was all fine and dandy, but was for the case of single-use. I needed a way to clean up event listeners on a Node.js net.Server and associated socket connections.

 

 

JavaScript Inheritance and Method Overriding

I’m always finding myself wanting to use JavaScript like a classical OOP language with class-based inheritance, even though I know it is prototypical. Anyways, I’m jotting down how to do this and also allow for overriding (not overloading) methods. Note, that if you’re using Node.js, then you don’t need to define the inherits function, it is already available in require('util').inherits.

Check the console:

 

Node.js: Split/Count Number of Lines (Unicode Compatible)

The task was to read n number of a lines from a file in Node.js. The assumption is that the read buffer is UTF-8. The caveat is that there is more to just new lines in Unicode than “New Line (ASCII 10 or \n)” and “Carriage Return (ASCII 13 or \r)”.  This SO comment put me in the right direction.

Unicode Technical Standard #18 § 1.6 describes the following rule regarding line boundaries, (PS and LS are defined in Unicode 6.1 § 16.2 Layout Controls):

RL1.6 Line Boundaries
To meet this requirement, if an implementation provides for line-boundary testing, it shall recognize not only CRLF, LF, CR, but also NEL (U+0085), PS (U+2029) and LS (U+2028).

To put it into practice, the number of lines can be tallied while the ReadStream has incoming data:

The key is the regular expression, derived straight from RL1.6,  /\r\n|[\n\r\u0085\u2028\u2029]/ , which looks for any of the possible new line characters with precedence to CRLF (greedy). Don’t forget to listen for the “end” event and also remove the “data” listener on “end” or “error!”

In the context of splitting incoming data by line, simply calling  chunk.toString('utf8').split(/\r\n|[\n\r\u0085\u2028\u2029]/g) will do the trick. Note that if working with CSV files, parsing will require a bit more effort if escaped new-lines will need to be taken into consideration, and PS, LS and NEL are probably not characters that should act as line delimiters in that context anyway.

Node.js: Handling File Uploads without Express

I was working on a little project which does not utilize express. Part of the program needed to handle file uploads. In PHP this is easy with the $_FILES superglobal, and with express this is also just as easy with req.files. In pure node.js the developer doesn’t have this luxury because they’re just dealing with raw http requests and responses (I’m surprised node.js even parses the headers, it is a miracle!). Before I begin, this whole process should be optimally streamed to a file so large file uploads do not consume more RAM than their response chunk size, but I didn’t do this, shame on me.

First, capture the response body. Here I am assuming you have a HTTP server that is listening and responding to requests:

Here, I’ll give you the entire source to my MultipartParser Node.js module. It requires nodeproxy.

And the implementation is as follows:

LittleDiddy does not have any path routing (e.g. it won’t actually show a form that uses enctype="multipart/form-data"), it simply accepts and parses a POST with “file” inputs. This “little diddy” (implementation example) is untested by the way, so good luck.

This article’s source is released under the MIT license; I don’t care what you do with it.