обработка исклучений
 

2 варианта:

1-й

function a(node) {
 var t = node.firsChild;
}

2-й

function a(node) {
 if(node) var t = node.firsChild;
 else throw Error('node is undefined');
}

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

Может я чегот не знаю, что должно было меня склонить ко второму варианту? (видел многие используют)

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

ИсклЮчений!

ну пример просто ради примера.
у меня в коде эксепшены остались только в очень больших функциях. И закоменчены для дебагинга(например если extend переписывает сущ св-во).

вот я у думаю стоит придерживаться какой-то одной линии(писать на все функции), или можно в разброс ка сейчас.

очепятка

Поэтому не минус)

Предположим есть функция которая вычисляет цену товара с учетом НДС:

function calcPrice(basePrice) {
    return basePrice * 1.2;
}

Однако даже если предположить что передаваемый в нее параметр basePrice всегда является числом, то есть ситуации когда параметр будет невалиден, например, если цена отрицательная. В таком случае функция отработает нормально, но полученный результат будет некорректен и все последующие операции с этим результатом будут бессмысленны. Таким образом необходимо остановить выполнение скрипта. В этой ситуации можно применить исключение, которое будет уведомлять об ошибке:

function calcPrice(basePrice) {
    if (basePrice < 0) {
        throw 'Price can not be negative.';
    }

    return basePrice * 1.2;
}

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

float, если твой вопрос ограничивается только работой с параметрами функции и некоего общего подхода...
Мы у себя используем следующий вариант.

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

function a(node,type) {
   type=type || true;
}

DreamTheater, теперь понятно о чём вопрос.

Применяем такое только в самых "труднодоступных" местах. Для выявления охайников, которые так умудряются запутать алгоритм движка, что только таким образом остановив выполнеие скрипта/программы можно по стеку ошибки вычислить охайника и привести его алгоритм к путёвому виду. :)

+1 Если допустимы некие умолчания при некорректных входных данных, то просто исправляем их и скрипт работает дальше, но иногда правильная информация на входе просто must have.

Например вот так:

function calcPrice(basePrice) {
    if (typeof(basePrice) !== 'number') {
        throw 'Price must be a number.';
    }

    if (basePrice < 0) {
        basePrice *= -1;
    }

    return basePrice * 1.2;
}

DreamTheater, а если человек чисто случайно передал в вашу ф-цию строку с числовым значением? Ну, скажем, значение у input'а получил, и отдал без parseInt'а...

Не, в моём случае нет никаких расчётов и структура плоская и понятная.
речь как раз о функциях в который не передан node.
тоесть дать коду упасть(и тогда всё равно можно легко понять почему он упал) или обработать этот вариант и разжевать в консоли почему всё упало

Это уже детали, я лишь показал основную суть.

Ну, в принципе, да)

т.е. получается надо использовать исключения либо по причине качества кода, либо чтобы долго не искать причину в большом проекте... Исправлять некорректные данные? Разве это не ведет к некачественному коду, если мы говорим о внутренних данных? В любом случае советы довольно нечеткие. Я например не понял, когда наступает must have, и насколько полный этот must have. В каких конкретно случаях их использовать, в каких не использовать. Проверять все параметры или выборочно. Насколько тщательно их проверять. Понял только основную суть: бывает нужно :)

Я тебе советую сейчас не использовать исключения. В результате, если, например, ты начнешь часто себя заставать за тем, что долго ищешь причину ошибки, у тебя будут конкретные примеры под рукой и ты сможешь принять более удачное решение (выработать какие-то конкретные правила, например, или выяснишь, что все потому что что-то там написано как попало), чем будешь сейчас использовать исключения на всякий случай.

У нас получается, что так. На данный момент их в движке осталось 3. Одно контролирует дату, остальные два контролируют структурные моменты...

Правда оговорюсь, это не JS программки. Но этот подход я бы примени и к JS... Поскольку пока не вижу в чём-то другом особого смысла в прерывании программы именно по "своей ошибке", а не ошибке исполнения...

3 вида исключений или 3 места, где генерируется исключение? И как вы определились с этими местами?

3 места... :) Ну и 3 разных сообщения при прерывании...
Выявили самое "остриё" и там поставили анализ+прерывание. Пример кода тут мало чего даст, т.к. он не на JS (как я уже писал)...