Вслед за Groupon, Paypal осознал могущество Node.js

По правилу 95% побеждает самая говенная технология %)

Месье не пользуется поделками для хипстеров и использует async.

Про слабую типизацию в энтерпрайзе даже говорить не хочется.

И не говори, а то я от смеха умру.

Например, как ты ловишь исключения случившиеся в колбеках к монгустовским коллекциям?

Домены же есть, для тех кто любит писать пуляющий эксепшенами код.

И мусье настолько чакнорист, что никогда не прозевает вызов колбека?

Зевают обычно поставить return после колбека. Но это можно прописать в coding style. Не проблема, в общем.

А так да, о переносе кода из браузера на сервер рассуждают только фантазёры.

Месье не пользуется поделками для хипстеров и использует async.

ЛОЛ. Собственно дальше можно и не продолжать.

var async = require('async')

async.series([
    function (cb) {
        throw new Error('boo')
    }
], function done(err) {
    console.error('Error catched! Хуй там', err)
})

Если тебе такое поведение кажется правильным, то у меня для тебя плохие новости.

Домены же есть

Которые появились совсем не давно. Но уверен что этот нодофаг про них не знает. А если у контекстных объектов нет on('error'), то домены превращаются в тыкву.

для тех кто любит писать пуляющий эксепшенами код.

Ни для кого не секрет, что большинство нодовских библиотек — кривое недописанное говно. Куда не плюнь — одни поделки. Чего собственно ждать от клиентсайдеров.

throw new Error('boo')

Дальше не читал. Иди уроки делай.

И в чем смысл кидания эксепшена, если для этого есть return cb(err)?

Типа, наши отцы и деды кидали эксепшены, поэтому и нам следует?

Ну дык надо выбирать хорошие библиотеки, а не говяные, и не мешать стиль программирования.

Поправлю, что код выше верен вообще для любой событийной модели. Думаю, что объяснять почему не надо?

По логике код должен быть примерно (поправьте ошибки) такой:

function badFunction() {
   throw "boo"
}

async.series([
    function (cb) {
       try {
         badFunction()
       } 
       catch(err) {
         console.error('Error catched! ', err)
       }
    }
], function done(err) {
    console.error('Callback completed! ', err)
})

Типа, наши отцы и деды кидали эксепшены, поэтому и нам следует?

Странно, я думал что ты умный человек, но видимо знакомство с нодой не для всех проходит даром. Ну да ладно.

Если не настроить аккуратно домены, и если на месте моего явного исключения будет неявное, то легко получается тихое исключение. Оно нигде не логируется, узнать о нем можно только по сайд эффектам и трейса естественно не будет. Happy debuging на ровном месте.

Поправлю, что код выше верен вообще для любой событийной модели.

Нет. Гринлеты или генераторы позволяют получать исключения на верхнем уровне.

По логике

Я не должен любой пук оборачивать в try/catch.

И в чем смысл кидания эксепшена, если для этого есть return cb(err)?
Типа, наши отцы и деды кидали эксепшены, поэтому и нам следует?

Встроенные методы ты тоже будешь переписывать? Проблема в том, что любой ЯП, который имеет эксепшены сам их использует по полной программе. В идеале, ноду вообще надо содержать на своем движке с выпеленными начисто эксепшенами. Только результаты возратов.

Кстати, а как ты относишься к факту, что после пойманного доменом исключения нужно убивать воркер? По моему это полный абзац.

Но не возникает никакого желания по перенесению кода с одной стороны на другую.

я (и далеко не только я) допускаю ошибки, когда приходится быстро переключаться с одного яп на другой. и был бы крайне рад, если бы меня лишили такой необходимости.

правда нода мне тоже не очень понравилась.

В идеале, ноду вообще надо содержать на своем движке с выпеленными начисто эксепшенами. Только результаты возратов.

Это уже будет не js. А единый язык на фронте беке это же так важно, гг!

Ну дык надо выбирать хорошие библиотеки

Назови хороший soap клиент и хороший xml парсер, поддерживающий неймспейсы и xpath2 )))

В школе не учили ставить логер в process.on('unhandledException',...) и оборачивать проблемные места локально в try/catch ? Бывает.

Гринлеты или генераторы позволяют получать исключения на верхнем уровне.

http://stackoverflow.com/questions/7310521/node-js-best-practice-exception-ha...

http://machadogj.com/2013/4/error-handling-in-nodejs.html

и оборачивать проблемные места локально в try/catch ?

Исключения бывают только в однозначно идентифицируемых «проблемных местах»? o_O

и в большинстве случаев код может перетекать туда сюда

При работе с node.js такого не случается практически никогда. Я такое видел только один единственный раз, в случае с малюсенькой библиотечкой для склонения слов русского языка по числам и падежам, которая была вещью в себе. В остальных случаях такой перенос будет скорее всего даже технически невозможен.

Откуда мне знать про библиотеки, которыми я не пользуюсь? Те что у меня - либо были нормальные либо были портированы из других языков, и теперь нормальные. Если вы хотите использовать молодую платформу, но вместо того чтобы улучшать библиотеки устраивать истерики про эксепшены в коде - ну значит судьба у вас такая.

Как бе куча библиотек работающих как в браузере, так и на ноде. Ведь js это не только работа с деревом. Тут всё от задачи зависит.

А что за control flow решения?

На самом деле, сейчас тысячи их. Это стало так же модненько, как и лабать мультимедиа-проигрыватели под линукс. Каждый пишет, кто во что горазд.

Вот, меня недавно приглашали в alma mater сделать презентацию на эту тему, вроде бы захватил самые популярные.

куча библиотек работающих как в браузере, так и на ноде

Если бы ты заглядывал хоть в одну из них, ты бы знал, какими уродливыми костылями достигается такая «платформонезависимость».

Исключения бывают только в однозначно идентифицируемых «проблемных местах»? o_O

Если код проектируют головой, а не задницей, придерживаясь принципа микромодульности, то эксепшены за пределы модуля не улетают, либо такие места легко находятся по логам из глобального хендлера или доменам.

Если код проектируют головой, а не задницей, придерживаясь принципа микромодульности, то эксепшены за пределы модуля не улетают

Если только весь модуль, целиком, в try заключить. В противном случае идеальная лодка сразу разобьётся о реалии жизни :) Даже в модуле в 5 строк исключение зевнуть вполне реально.

и оборачивать проблемные места локально в try/catch ?

Исключения бывают только в однозначно идентифицируемых «проблемных местах»?

Обычно там все проще. Если ты не пишешь библиотеку, которая не должна тянуть зависимостей, и не брезгуешь пользоваться обертками для control flow, то все исключения (независимо, в синхронной ли или асинхронной части) ловятся автоматически там, где тебе удобно их обрабатывать, либо же передаются в коллбэк наверх в качестве err-аргумента.

Костыль это детект того что код исполняется в браузере? ЛОЛ.

Это библиотеки типа async, промисы, корутины и т.п. Короче, штуковины, позволяющие превратить макароны из тонны вложенных лямбд во что-то более плоское.

https://github.com/caolan/async

Вот слова не восторженного школьника, но опытного мужа. Хоть кто то понимает мою боль xD.

Одно радует — скоро я перестану использовать ноду, забуду ее как страшный сон и вернусь на питон.

Костыль это детект того, что в чьей-то воспаленной фантазии возникла идея пользоваться серверным кодом на клиенте.

То есть вы не зная нодовских инструментов и специфики проектирования решили просто поумничать, увидев знакомое слово «эксепшен» ?

Одно радует — скоро я перестану использовать ноду, забуду ее как страшный сон и вернусь на питон.

Смотри, как бы возвращение не оказалось для тебя разочарованием ;)

то все исключения ловятся автоматически там, где тебе удобно их обрабатывать

Не всегда. Выше я уже показал что это не так. Точно знаю что Q ловит, но переход между prоmise-aware и колбечным кодом леденит душу, поэтому от Q отказались.

Потому что могут. Тут вон выше неосилятор подпирая порванную попку рыдает о том какая же нода плохая, а всё потому что неосилил. Беда, печаль.

Потому что Q - это жирная страшная поделка, которая абсолютно не способствует написанию хорошего кода на node и сама таковым не является.

Смотри, как бы возвращение не оказалось для тебя разочарованием ;)

У нас уже давно есть правильная автоматическая асинхронность в лице gevent. И yield from в тройке. Поэтому маразма с колбеками и исключениями не наблюдается.

Желаю ноде поскорей перейти на генераторы, иначе годика через полтора волна хайпа пойдет в обратку. Хотя зная разрабов, это опять будет сделано через жопу.

Потому что могут

ок

которая абсолютно не способствует написанию хорошего кода на node и сама таковым не является.

Оба на. Раз ты в теме, каким контролфлоу пользуешься?

Желаю ноде поскорей перейти на генераторы

Это будет действительно качественный скачок. Но ходят слухи, что мэйнтейнеры нода как-то косо поглядывают на генераторы и в целом эту затею не приветствуют.

И? Да я обо всем этом знаю. То что надо каждый раз танцевать вокруг исключений это нормально? Тем более uncaughtException вообще не решает проблему. Только домены и то довольно таки специфично.

В этой ситуации печальнее всего что 99% нодовцев вообще не понимают в чем проблема.

Что есть «встроенные методы»? Если подразумевается внешняя библиотека, на которую я не могу повлиять напрямую, то я шлю багрепорт, и ее срочно фиксят. Потому что все нормальные люди понимают, что в ноде ошибки надо возвращать через колбеки и эксепшенов быть не должно. Если речь о моем коде - ну я знаю что JSON.parse может кинуть эксепшен и оборачиваю в try/catch, но таких место не особо много.

Соответственно, когда придерживаются этого принципа, то глобальных хендлеров эксепшенов и доменов обычно хватает, чтобы быстро найти проблемное место.

Иногда может потеряться часть стектрейса на nextTick, но это обычно если евенты пытаются тащить не туда где надо. Просто надо учитывать специфику разработки на ноде и не устраивать там ынтырпрайзов когда сначала лепят код а потом думают что с ним делать.

каким контролфлоу пользуешься

Самописным, большего и не нужно было. Правда, уже почти год как на ноде не пишу.

это называется наследование

ctrl+c, ctrl+v ?

Ты уверен?

Да. Пруф.

код выше верен вообще для любой событийной модели.

в тойже яве есть exceptionHandler, да и вообще там только в одной школьной поделке (кучке executors из util.concurrent) эксепшены тупо задавливаеются

а вот в js это норма поведения, потому найти сточник ошибки просто невозможно

Самописным

Гг. Это как любой лиспер должен написать свой интерпретатор.

Тоже свой, только колбэки используются явно, обертка над async, позволяет расставлять точки синхронизации между параллельными секциями и наследовать родительский контекст.

Built almost twice as fast with fewer people
Written in 33% fewer lines of code
Constructed with 40% fewer files

Лалки, с любым не жаба языком вышло бы так же.

Так вышло бы с любым вторым языком. Все костыли и грабли уже собраны, требования хорошо известны, если не случится «эффект второй системы» - при переписывании будет лучше.

«эффект второй системы»

А что это за зверь такой?