No need to (ab)use Function.prototype, just make "xie" a regular function:
var xie = function exitIfError(exitCode, f) {
// Same body as yours above
}
code collapses to just
ec2.runInstances({ ... }, xie(1, function (runInstancesResponse) {
// ... get the instanceIds from response as input to createTags
ec2.createTags({ ... }, xie(2, function (createTagsResponse) {
// ... do further processing ...
}));
}));
Though, you may want to check out a module like async[1], your entire code
would look like this:
async.waterfall([
function (callback) {
ec2.runInstances.bind(ec2, { ... }, callback);
},
function (runInstancesResponse, callback) {
// ... get the instanceIds from response as input to createTags
ec2.createTags({ ... }, callback);
},
function (createTagsResponse, callback) {
// ... do further processing ...
callback();
};
], function (err) {
if (error) {
console.log(error);
process.exit(1);
}
});
In my opinion, this kind of thing makes for much more readable and
maintainable code for asynchronous operations, avoids the nasty nesting
that happens once you're up to 5-10 operations happening in serial.
[1] https://github.com/caolan/async#waterfall
On Tuesday, March 19, 2013 4:44:05 PM UTC-7, Ken wrote:
>
> I've been writing a bunch of shell-script-like node scripts lately. These
> mostly call a series of async functions that take the usual function
> (error, data) { ... } callback, and generally they handle any error along
> the way by logging it and exiting. Here's a naive example using aws-sdk to
> make a couple EC2 API calls in serial
>
> var AWS = require("aws-sdk");
>
> var ec2 = new AWS.EC2.Client();
>
> ec2.runInstances({ ... }, function (error, runInstancesResponse) {
> if (error) {
> console.log(error);
> process.exit(1);
> } else {
> // ... get the instanceIds from response as input to createTags
> ec2.createTags({ ... }, function (error, createTagsResponse) {
> if (error) {
> console.log(error);
> process.exit(2);
> } else {
> // ... do further processing ...
> }
> });
> }
> });
>
> As you can see a lot of the total lines are just totally boilerplate if
> (error) barf. Since we've got a functional language here, pretty easy to
> encapsulate that, e.g. with this
>
> Function.prototype.xie = Function.prototype.exitIfError = function
> (exitCode) {
> var f = this;
> return function (error, data) {
> if (error) {
> console.log(error);
> process.exit(exitCode || 1);
> } else {
> f.call(this, data);
> }
> };
> }
>
> our code collapses to just
>
> ec2.runInstances({ ... }, function (runInstancesResponse) {
> // ... get the instanceIds from response as input to createTags
> ec2.createTags({ ... }, function (createTagsResponse) {
> // ... do further processing ...
> }.xie(2));
> }.xie(1));
>
> Which feels a lot more readable to me. Is there precedent for this
> technique? A name for it? Any well known modules that implement it? Any
> obvious horrible side effects? Clearly not applicable to sophisticated
> error handling, but for this basic "it all works or just give up" kind of
> thing it seems handy. Could add "abort if error", "throw if error", "emit
> if error" flavors as well.
>
>
--
--
Job Board: http://jobs.nodejs.org/
Posting guidelines:
https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en
---
You received this message because you are subscribed to the Google Groups
"nodejs" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
