Try-catch предназначен для предотвращения или обработки ошибок? (в JavaScript)

1

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

Это мой подход к коллеге:

import Config from 'config';

export const getUserFromLocalStorage = () => {
  const key = Object.keys(localStorage).find(value => value === '${Config.applicationId}/currentUser');

  try {
    return key ? JSON.parse(localStorage[key]) : {};
  } catch (e) {
    return {};
  }
};

Это означает, что он не заботится об данной ошибке, и он просто переносит возвращающий объект, чтобы продолжить процесс

и мой:

import Config from 'config';

export const getUserFromLocalStorage = () => {
  const key = Object.keys(localStorage).find(value => value === '${Config.applicationId}/currentUser');

  try {
    return key ? JSON.parse(localStorage[key]) : {};
  } catch (e) {
    console.log('the given error', e); // Just simple notifier for this example
  }
};

но мой подход по-прежнему имеет проблему, которая заключается в том, что он вернет undefined (что может привести к сбою внутри моего приложения), что может легко исправить его, используя, finally и вернуть значение по умолчанию, но это не кажется мне хорошей практикой.


ВОПРОС

Итак, что будет использовать баланс, используя try catch и, finally при необходимости, чтобы сделать мое приложение стабильным.
Что-то не так с нашим подходом?
В частности, мы не можем доверять данным, которые localStorage из localStorage, и каков будет наилучший подход для этой реализации?

  • 4
    is that it will return undefined (which can crash internaly my app) : вы должны документально подтвердить, что метод может вернуть undefined и ваш код, вызывающий его, должен быть в состоянии это обработать. Точно так же пустой объект вашего коллеги может вызвать исключение для вызова кода. Главное - документировать то, что возвращается в состоянии ошибки, и позволить вашим абонентам решать, что делать.
  • 0
    Нет, вы бы не использовали, finally вернуть значение по умолчанию для случая ошибки.
Показать ещё 3 комментария
Теги:
web
try-catch
local-storage
web-storage

3 ответа

3

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

Возможно ли, что сохраненное значение недействительно JSON? И у вас есть "план резервного копирования" для того, что делать в этом случае? И нет ничего, что может сделать пользователь и/или разработчик? Тогда никого не беспокоить. Возможно, вы хотите console.log сообщение, которое может помочь в отладке, но кроме этого просто продолжайте с потоком программы. Там, безусловно, не нужно беспокоить пользователя alert если: а) пользователь не инициировал действие и б) им тоже ничего не нужно делать.

Соображения:

  1. Независимо от того, чтобы catch ошибку в первую очередь:

    • это ожидаемая ошибка, которая может произойти, естественно, во время потока программы?
    • это ошибка, о которой вы можете что-то сделать?
    • у вас есть какой-то план, что делать, если вы поймали ошибку?

  2. Записывать ли ошибку:

    • делает ли этот журнал кому угодно?
    • будет ли кто-нибудь когда-нибудь видеть запись в журнале?
    • дает ли она кому-либо полезную информацию, которая может привести к устранению проблемы?

  3. Что-то об ошибке:

    • инициировал ли пользователь действие?
    • пользователь ожидает некоторую форму ответа, положительную или отрицательную?
    • может ли пользователь сделать что-нибудь, чтобы исправить эту проблему?

Возвращать пустой объект или ничего /null/undefined зависит от того, что такое функция. Является ли функция, определенная для того, чтобы всегда возвращать объект? Затем он должен return {} из catch. Или "ничего" действительный ответ, когда ожидаемого объекта не существует? Тогда, возможно, return false.

В целом, подход моего коллеги кажется мне очень разумным.

Поделиться
  • 0
    Хорошо, если по какой-либо причине в localStorage есть недопустимый объект JSON, и я localStorage пустой объект, предполагая, что getUserFromLocalStorage всегда будет работать и возвращать что-то (действительное), что является «неправильным»? Так как произошла ошибка, я понимаю ваше объяснение. На самом деле, мы не должны даже возвращать пустой объект, если ключ не существует. Я предполагаю, что все зависит от того, что контракт для функции getUserFromLocalStorage . что ты думаешь? :)
  • 1
    Ошибки не всегда являются фатальными, то есть в обычном потоке программы могут быть ожидаемые ошибки, которые можно просто обработать без предупреждения (скрытые под ковриком). Ошибка! == всегда звучит сигнал тревоги. Помимо этого, да, вы сами решаете, как ваша функция должна вести себя снаружи.
Показать ещё 1 комментарий
1

В этом конкретном случае, когда вы работаете с localStorage (что почти всегда неизбежно означает работу с JSON.parse()), всегда рекомендуется перевернуть обработку в try-catch. Это связано с тем, что как localStorage, так и JSON.parse имеют исключения как нормальную часть обработки ошибок, и, как правило, можно с легкостью вернуться к умолчанию или первоначальному значению.

Образец, который я использую, выглядит следующим образом:

const DEFAULT_VALUE = {};
try {
  const result = JSON.parse(result);
  return result || DEFAULT_VALUE;
} catch (e) {
  console.warn('Error parsing result', e);
} 

return DEFAULT_VALUE;

Таким образом, у вас есть последовательная обработка ошибок и возврат значения по умолчанию.

В общем, вам не нужно использовать try-catch, если вы не можете и будете безопасно обрабатывать ошибку и генерировать полезную резервную копию. По этой причине большинство блоков try-catch имеют тенденцию сидеть у основания стека вызовов, так что они улавливают незапланированные ошибки, обрабатывают их изящно для пользователя, но записывают их шумно с помощью стека вызовов на консоль для разработчика правильно исследовать/обрабатывать/работать.

Поделиться
0

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

Поэтому я считаю, что наилучшей практикой является использование try для запуска кода и catch если есть какие-либо ошибки, и уведомлять разработчика и/или пользователя о наличии исключения и использовать, finally для преодоления исключения путем возвращения действительного объекта.

Таким образом, пользователь также может продолжить работу, и разработчик также может проверить ошибку в файле журнала для будущей отладки. Это моя личная идея.

Поделиться

Ещё вопросы

Сообщество Overcoder
Наверх
Меню