The JavaScript blog.


tutorials testing angularjs error-handling

AngularJS Form Errors, Angular Integration Tests

Posted on .

AngularJS: API Error Code Handling in Forms

When you're writing forms with Angular, it's not always clear how to handle errors in a reusable way. For example, what format should the server use to send back structured error message to the client? How do you use these responses to annotate fields with errors?

Szymon Kosno sent in AngularJS: API Error Code Handling in Forms, a tutorial that shows how to use error handling without explicit error handling in view controllers. It makes suggestions for how to structure detailed JSON error responses, and how to support different types of errors: for example, global errors and errors for specific form fields.

The form's markup uses an api-validate directive for input elements that should be validated by the server and will show error annotations. This allows the underlying error handling code to determine that the field is API error aware, so errors can be displayed or hidden as required.

With the right directives and services, Szymon is able to remove custom error handling code, which really cleans up the associated controllers. This article is useful if you've ever been confused about how to handle server-side errors, which you should always do for security and sanity.

Angular Integration Tests

Torgeir Helgevold sent in Angular integration tests, which gives some background to integration tests and includes a detailed example towards the end of the article.

In the following example I will demonstrate how to test a series of nested components with shared state. My sample code includes a parent directive where a user can add an inputed number to a list by clicking a button. Nested within there are two directives, one for calculating the sum of all items, and a second directive for building a comma separated string from the items in the list.

The example uses Angular's controllerAs syntax to simulate isolated scopes and pass changes. If you've ever used something like Selenium for integration tests, then you might want to compare Torgeir's approach if you're looking for something more lightweight and focused.


libraries node modules hardware iojs error-handling

Node Roundup: io.js, npm and jQuery, error-system

Posted on .


Last Friday, io.js 1.5.0 was released, which is another major milestone for the project. It introduces a new Buffer.prototype.indexOf method, which is like Array.prototype.indexOf. This is implemented in node_buffer.cc, and works with strings and numbers.

Last week Rodd Vagg posted a comment about io.js on DailyJS to say that the ARMv8 support is separate to the earlier Node support for ARMv6 and 7, and it actually sounds quite significant. According to last week's release notes, Linaro has contributed hardware to help io.js with ARMv8:

this is an entirely new architecture from ARM that adds 64-bit support which they are heavily pursuing the server market with. io.js (Node) + ARMv8 on the server is an amazing opportunity and ARM have been lending their support to the io.js project to make this work.

64bit ARM means more RAM in Android phones and tablets, which is great. But what about servers -- are we going to be able to use low-powered clusters of powerful ARM machines? Linaro has details on its ARM servers, and has an application form for people to request access to try them out. Linaro says it's planning to use servers are based on Opteron A1100 Cortex-A57, and X-Gene.

The best place to read more about the latest io.js release is the io.js Week of March 6th post on Medium. Which reminds me, there's an @iojs Medium account which is definitely worth following.

npm and jQuery

The npm weekly update points to yet another npm and jQuery plugin article. This one talks about how to make your own jQuery plugins make better use of npm. This includes referencing stylesheets in package.json and CommonJS compatibility.


Something I like to do in my Node-based web apps is include an errors.js file that subclasses Error with constructors named after HTTP errors. It makes it easier for me to pass the right error into next (in Express/Connect) so the error gets passed along to a centralised error handler. The way I do it is basic old skool JavaScript, so I've been looking for ways to improve it

Fomichev Kirill noticed Rod Vagg created node-errno. Rodd's module includes errors for libuv and Node, so you can check error codes with expressions like require('errno').code.ENOTEMPTY. You can also use it as a command-line tool for checking Node errors, and it has an API for making custom errors. The custom errors include the call stack, and it allows error hierarchies to be created.

Inspired by this, Fomichev made error-system (GitHub: fanatid/error-system, License: MIT, npm: error-system). It's similar to Rodd's module, but is designed specifically for creating custom errors. If you were making a web application, you could make a class for request errors like this:

var errorSystem = require('error-system')  
var RequestError = errorSystem.createError('RequestError', 'Code: {0} (url: {1})')  

This is exactly what I wanted when I made my original errors.js file. I particularly like the numbered arguments in Fomichev's module because it cuts down the amount of boilerplate when compared to my solution.