Попытка получить значения из undefined в Javascript вызывает исключение TypeError. Я читаю книгу, в которой говорится, что вы можете защитить эту ошибку от оператора & &. Однако он не говорит, почему я хотел бы подавить ошибку. Может кто-нибудь объяснить, почему это было бы полезно?Подавление исключения TypeError в Javascript
Когда возникает ошибка типаError, генерируется исключение, и эта ветвь кода прекращает выполнение (если исключение не обрабатывается). Это обычно нежелательное условие.
Таким образом, можно написать код, который проверяет, действительно ли объект действителен, прежде чем пытаться получить доступ к свойствам на нем. Существует несколько способов структурирования этого типа кода в зависимости от того, что вы проверяете.
Например, если у вас есть объект, и вы хотите, чтобы прочитать свойство на него, и вы не уверены в том случае, если объект будет действительно, вы можете сделать это:
function speak(obj) {
if (obj) {
console.log(obj.greeting);
}
}
Этот вид кода будет безопасным, действительно ли obj действителен или нет. Если вы выберете if (obj), то этот код будет генерировать исключение и прекратить выполнение, если obj не был действительным объектом.
Если, с другой стороны, obj всегда должна быть действительным объектом, и вы хотите, чтобы программа, чтобы остановить выполнение с видимым исключением, если obj не является допустимым объект, то вы можете пойти без if проверки и просто убедитесь, что вы достаточно проверили свою программу, чтобы убедиться, что obj всегда действителен до его использования. В коде, который я пишу, независимо от того, проверяю ли я такие аргументы, часто зависит от того, контролирую ли я то, что было передано функции, или кто-то другой контролирует это. Если я нахожусь под контролем, то я знаю, будет ли obj действительным или мне нужно проверить на достоверность. Если кто-то еще находится под контролем, то я не знаю, будет ли всегда оставаться obj, поэтому может быть желательно его протестировать.
Средство, выбранное некоторыми библиотеками, должно предлагать режим «отладки», который делает незапланированные ошибки очень заметными (протоколирование) и «производственным» режимом, который пытается продолжать работу как можно лучше, не останавливая выполнение. Значительно другое поведение в режиме отладки или режиме производства также может быть источником проблем, поэтому нужно быть осторожным с этим.
... Вы спрашиваете, почему было бы полезно не убить вашу программу? Вам действительно нужно объяснение, почему плохо, если ваша программа терпит неудачу и завершается в несколько непредсказуемом состоянии для ваших пользователей? – meagar
Я думал, что было бы плохо попытаться получить доступ к данным, которых не существует, и я хотел бы знать, где это происходит, поэтому я могу это исправить. Мой опыт в том, что вы ломаете ошибки и делаете что-то в этом роде, а не просто пахаете через них. – user137717
Существует множество ситуаций, когда ваш код должен полагаться на ввод пользователя. Если введен неверный ввод, с проверкой данных вы можете назначить значение по умолчанию или запросить у пользователя правильную информацию. – Teemu