Nodejs обработка ошибок - История изменений

imported>Supportadmin: /* Безопасная обработка ошибок */

2014-04-10T09:07:37Z

Безопасная обработка ошибок

← Предыдущая версия		Версия от 12:07, 10 апреля 2014
Строка 132:		Строка 132:
	<nowiki>var d = require('domain').create();		<nowiki>var d = require('domain').create();
	d.on('error', function(err){		d.on('error', function(err){
	// ~~handle the error safely~~		// безопасная обработка ошибки
	console.log(err);		console.log(err);
	});		});

	// ~~catch the uncaught errors in this asynchronous or synchronous code block~~		// обработка непойманных ошибок в синхронном или асинхронном блоке кода
	d.run(function(){		d.run(function(){
	// the asynchronous or synchronous code that we want to catch thrown errors on		// the asynchronous or synchronous code that we want to catch thrown errors on

imported>Supportadmin: /* Безопасная обработка ошибок */

2014-04-10T09:04:05Z

Безопасная обработка ошибок

← Предыдущая версия		Версия от 12:04, 10 апреля 2014
Строка 128:		Строка 128:
	Иногда, может быть код, который выдает где-то ошибки, которые могут привести к неперехваченным исключениям и потенциальному краху нашего приложения, если мы безопасно не обработаем их. В зависимости от нашей архитектуры кода мы можем использовать один из следующих методов, чтобы обработать ошибку:		Иногда, может быть код, который выдает где-то ошибки, которые могут привести к неперехваченным исключениям и потенциальному краху нашего приложения, если мы безопасно не обработаем их. В зависимости от нашей архитектуры кода мы можем использовать один из следующих методов, чтобы обработать ошибку:

	~~When we know where the error is occurring~~, ~~we can wrap that section in a~~ node.js domain		Когда мы знаем где может произойти ошибка, мы можем обернуть этот участок кода в node.js domain

	<nowiki>var d = require('domain').create();		<nowiki>var d = require('domain').create();

imported>Supportadmin: /* Безопасная обработка ошибок */

2014-04-10T09:02:14Z

Безопасная обработка ошибок

← Предыдущая версия		Версия от 12:02, 10 апреля 2014
Строка 126:		Строка 126:
	==Безопасная обработка ошибок==		==Безопасная обработка ошибок==

	Иногда, может быть код, который выдает где-то ошибки, которые могут привести к неперехваченным исключениям и потенциальному краху нашего приложения, если мы безопасно не обработаем их. В зависимости от нашей архитектуры кода мы можем использовать один из следующих методов, чтобы ~~поймать его:~~		Иногда, может быть код, который выдает где-то ошибки, которые могут привести к неперехваченным исключениям и потенциальному краху нашего приложения, если мы безопасно не обработаем их. В зависимости от нашей архитектуры кода мы можем использовать один из следующих методов, чтобы обработать ошибку:
	Sometimes though, there may still be code that throws an error somewhere which can lead to an uncaught exception and a potential crash of our application if we don't catch it safely. Depending on our code architecture we can use one of the following methods to catch it:

	When we know where the error is occurring, we can wrap that section in a node.js domain		When we know where the error is occurring, we can wrap that section in a node.js domain

imported>Supportadmin: /* Безопасная обработка ошибок */

2014-04-10T09:01:32Z

Безопасная обработка ошибок

← Предыдущая версия		Версия от 12:01, 10 апреля 2014
Строка 126:		Строка 126:
	==Безопасная обработка ошибок==		==Безопасная обработка ошибок==

			Иногда, может быть код, который выдает где-то ошибки, которые могут привести к неперехваченным исключениям и потенциальному краху нашего приложения, если мы безопасно не обработаем их. В зависимости от нашей архитектуры кода мы можем использовать один из следующих методов, чтобы поймать его:
	Sometimes though, there may still be code that throws an error somewhere which can lead to an uncaught exception and a potential crash of our application if we don't catch it safely. Depending on our code architecture we can use one of the following methods to catch it:		Sometimes though, there may still be code that throws an error somewhere which can lead to an uncaught exception and a potential crash of our application if we don't catch it safely. Depending on our code architecture we can use one of the following methods to catch it:

imported>Supportadmin: /* Safely "catching" errors */

2014-04-10T08:58:44Z

Safely "catching" errors

← Предыдущая версия		Версия от 11:58, 10 апреля 2014
Строка 124:		Строка 124:


	==~~Safely "catching" errors~~==		==Безопасная обработка ошибок==

	Sometimes though, there may still be code that throws an error somewhere which can lead to an uncaught exception and a potential crash of our application if we don't catch it safely. Depending on our code architecture we can use one of the following methods to catch it:		Sometimes though, there may still be code that throws an error somewhere which can lead to an uncaught exception and a potential crash of our application if we don't catch it safely. Depending on our code architecture we can use one of the following methods to catch it:

imported>Supportadmin: /* Nodejs domains */

2014-04-10T08:57:12Z

Nodejs domains

← Предыдущая версия		Версия от 11:57, 10 апреля 2014
Строка 171:		Строка 171:
	==Nodejs domains ==		==Nodejs domains ==

	nodejs domains is the most up to date way of handling errors in nodejs. Domains can caputure both error/other events as well as traditionally thrown objects. Domains also provide functionality for handling callbacks with an error passed as the first argument via the intercept method.		[http://nodejs.org/docs/v0.11.12/api/domain.html nodejs domains] is the most up to date way of handling errors in nodejs. Domains can caputure both error/other events as well as traditionally thrown objects. Domains also provide functionality for handling callbacks with an error passed as the first argument via the intercept method.

	As with normal try/catch-style error handling, is is usually best to throw errors when they occur, and block out areas where you want to isolate errors from affecting the rest of the code. The way to "block out" these areas are to call domain.run with a function as a block of isolated code.		As with normal try/catch-style error handling, is is usually best to throw errors when they occur, and block out areas where you want to isolate errors from affecting the rest of the code. The way to "block out" these areas are to call domain.run with a function as a block of isolated code.

imported>Supportadmin: /* Nodejs domains */

2014-04-10T08:49:45Z

Nodejs domains

← Предыдущая версия		Версия от 11:49, 10 апреля 2014
Строка 244:		Строка 244:
	This mimics a normal try-catch, even though the pieces are asynchronous. It would print:		This mimics a normal try-catch, even though the pieces are asynchronous. It would print:

	1		<nowiki>1
	2		2
	handler		handler</nowiki>

	Note that it doesn't print '3' because an exception was thrown that interrupts that flow.		Note that it doesn't print '3' because an exception was thrown that interrupts that flow.

	Take a look at these libraries:		Take a look at these libraries:

	https://github.com/kriskowal/q		*https://github.com/kriskowal/q
	https://github.com/fresheneesz/asyncFuture		*https://github.com/fresheneesz/asyncFuture

	Note that I haven't found many other libraries other than these that properly handle thrown exceptions. Jquery's deferred, for example, don't - the "fail" handler would never get the exception thrown an a 'then' handler, which in my opinion is a deal breaker.		Note that I haven't found many other libraries other than these that properly handle thrown exceptions. Jquery's deferred, for example, don't - the "fail" handler would never get the exception thrown an a 'then' handler, which in my opinion is a deal breaker.

imported>Supportadmin в 08:48, 10 апреля 2014

2014-04-10T08:48:53Z

← Предыдущая версия		Версия от 11:48, 10 апреля 2014
Строка 168:		Строка 168:
	var err = new Error('example');		var err = new Error('example');
	throw err;</nowiki>		throw err;</nowiki>

			==Nodejs domains ==

			nodejs domains is the most up to date way of handling errors in nodejs. Domains can caputure both error/other events as well as traditionally thrown objects. Domains also provide functionality for handling callbacks with an error passed as the first argument via the intercept method.

			As with normal try/catch-style error handling, is is usually best to throw errors when they occur, and block out areas where you want to isolate errors from affecting the rest of the code. The way to "block out" these areas are to call domain.run with a function as a block of isolated code.

			In synchronous code, the above is enough - when an error happens you either let it be thrown through, or you catch it and handle there, reverting any data you need to revert.

			<nowiki>try {
			//something
			} catch(e) {
			// handle data reversion
			// probably log too
			}</nowiki>

			When the error happens in an asynchronous callback, you either need to be able to fully handle the rollback of data (shared state, external data like databases, etc). OR you have to set something to indicate that an exception has happened - where ever you care about that flag, you have to wait for the callback to complete.

			<nowiki>var err = null;
			var d = require('domain').create();
			d.on('error', function(e) {
			err = e;
			// any additional error handling
			}
			d.run(function() { Fiber(function() {
			// do stuff
			var future = somethingAsynchronous();
			// more stuff

			future.wait(); // here we care about the error
			if(err != null) {
			// handle data reversion
			// probably log too
			}

			})});</nowiki>
			Some of that above code is ugly, but you can create patterns for yourself to make it prettier, eg:

			<nowiki>var specialDomain = specialDomain(function() {
			// do stuff
			var future = somethingAsynchronous();
			// more stuff

			future.wait(); // here we care about the error
			if(specialDomain.error()) {
			// handle data reversion
			// probably log too
			}
			}, function() { // "catch"
			// any additional error handling
			});</nowiki>
			UPDATE (2013-09):

			Above, I use a future that implies fibers semantics, which allow you to wait on futures in-line. This actually allows you to use traditional try-catch blocks for everything - which I find to be the best way to go. However, you can't always do this (ie in the browser)...

			There are also futures that don't require fibers semantics (which then work with normal, browsery javascript). These can be called futures, promises, or deferreds (I'll just refer to futures from here on). Plain-old-javascript futures libraries allow errors to be propagated between futures. Only some of these libraries allow any thrown future to be correctly handled, so beware.

			An example:

			<nowiki>returnsAFuture().then(function() {
			console.log('1')
			return doSomething() // also returns a future

			}).then(function() {
			console.log('2')
			throw Error("oops an error was thrown")

			}).then(function() {
			console.log('3')

			}).catch(function(exception) {
			console.log('handler')
			// handle the exception
			}).done()</nowiki>
			This mimics a normal try-catch, even though the pieces are asynchronous. It would print:

			1
			2
			handler
			Note that it doesn't print '3' because an exception was thrown that interrupts that flow.

			Take a look at these libraries:

			https://github.com/kriskowal/q
			https://github.com/fresheneesz/asyncFuture
			Note that I haven't found many other libraries other than these that properly handle thrown exceptions. Jquery's deferred, for example, don't - the "fail" handler would never get the exception thrown an a 'then' handler, which in my opinion is a deal breaker.

imported>Supportadmin в 08:40, 10 апреля 2014

2014-04-10T08:40:40Z

← Предыдущая версия		Версия от 11:40, 10 апреля 2014
Строка 122:		Строка 122:
	// Divide		// Divide
	divider.divide(4,2).divide(4,0);</nowiki>		divider.divide(4,2).divide(4,0);</nowiki>


			==Safely "catching" errors==

			Sometimes though, there may still be code that throws an error somewhere which can lead to an uncaught exception and a potential crash of our application if we don't catch it safely. Depending on our code architecture we can use one of the following methods to catch it:

			When we know where the error is occurring, we can wrap that section in a node.js domain

			<nowiki>var d = require('domain').create();
			d.on('error', function(err){
			// handle the error safely
			console.log(err);
			});

			// catch the uncaught errors in this asynchronous or synchronous code block
			d.run(function(){
			// the asynchronous or synchronous code that we want to catch thrown errors on
			var err = new Error('example');
			throw err;
			});</nowiki>

			If we know where the error is occurring is synchronous code, and for whatever reason can't use domains (perhaps old version of node), we can use the try catch statement:

			<nowiki>// catch the uncaught errors in this synchronous code block
			// try catch statements only work on synchronous code
			try {
			// the synchronous code that we want to catch thrown errors on
			var err = new Error('example');
			throw err;
			} catch (err) {
			// handle the error safely
			console.log(err);
			}</nowiki>

			However, there may still be a case where an uncaught error happens in a place that wasn't wrapped in a domain or a try catch statement, in which case to make our application not crash we can use the uncaughtException listener (however doing so can put the application in an unknown state):

			<nowiki>// catch the uncaught errors that weren't wrapped in a domain or try catch statement
			// do not use this in modules, but only in applications, as otherwise we could have multiple of these bound
			process.on('uncaughtException', function(err) {
			// handle the error safely
			console.log(err);
			});

			// the asynchronous or synchronous code that emits the otherwise uncaught error
			var err = new Error('example');
			throw err;</nowiki>

imported>Supportadmin: /* For eventful code */

2014-04-10T08:37:52Z

For eventful code

← Предыдущая версия		Версия от 11:37, 10 апреля 2014
Строка 87:		Строка 87:
	For eventful code, where the error may happen anywhere, instead of throwing the error, fire the error event instead:		For eventful code, where the error may happen anywhere, instead of throwing the error, fire the error event instead:

	<nowiki>// Definite our Divider Event Emitter		<nowiki>// Definite our Divider Event Emitter
	var events = require('events');		var events = require('events');
	var Divider = function(){		var Divider = function(){