try-catch是用来防止或处理错误的吗？（在javascript中）

最近，我与同事讨论了如何使用

try

和

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 {};
  }
};

Wich的意思是，他不关心给定的错误，他只是为了继续这个过程而返回一个对象

我的是：

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
  }
}; 

但我的方法仍然存在一个问题，那就是它将返回

未定义的

（这可能会在我的应用程序内部崩溃），最终可以使用

轻松修复它并返回默认值，但对我来说这听起来不是一个好的做法。




问题
那么，如果需要，使用
尝试
捕获
并最终
捕获
以使我的应用程序保持稳定，那么平衡会是什么呢
我们的方法有问题吗？

特别是，我们不能信任从
本地存储
提交的数据，因此，实现此功能的最佳方法是什么？
我认为最重要的是用户满意度。在一天结束时，该程序由普通用户使用。用户需要在不受任何中断的情况下使用该程序继续其工作

因此，我认为最佳实践是使用
try
运行代码并
catch
如果出现任何错误，并通知开发人员和/或用户存在异常，最后使用
返回有效对象以克服异常

这样，用户还可以继续工作，开发人员还可以检查日志文件中的错误，以便将来进行调试。
这是我个人的想法。
因为无论在哪种情况下，
最终都会执行，无论是否抛出了某些内容，它都不是返回默认值的地方。您是否需要详细记录错误也值得怀疑。这完全取决于某件事是预期的错误还是真正的例外情况，以及谁能做些什么

存储的值很可能是无效的JSON吗？你有一个“备份计划”在这种情况下该怎么做？用户和/或开发人员对此无能为力？那就不要用它来打扰任何人。也许您想要
console.log
一条可能有助于调试的消息，但除此之外，只需继续程序流。如果a）用户没有启动操作，b）用户也无需采取任何措施，则无需向用户发出
警报

应考虑的事项：

是否首先捕获一个错误：


这是程序流程中自然发生的预期错误吗
这是一个错误，你可以做些什么吗
如果你发现了错误，你有什么计划吗

是否记录错误：


这份日志对任何人都有好处吗
有人会看到那个日志条目吗
它是否为任何人提供了任何有助于解决问题的有用信息

是否对用户的某些内容进行错误提示：


用户是否发起了该操作
用户是否期望得到某种形式的响应，是肯定的还是否定的
用户能做些什么来解决这个问题吗

返回空对象还是不返回/
null
/
未定义
取决于函数的职责。函数是否定义为始终返回对象？然后它应该
从
catch
返回{}
。或者，当预期对象不存在时，“nothing”是有效的响应吗？然后可能
返回false

总的来说，您同事的方法对我来说似乎非常合理。
在这个特定的情况下，您使用的是
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块倾向于位于调用堆栈的底部，因此它们捕获计划外错误，为用户优雅地处理它们，但使用调用堆栈将它们大声记录到控制台，以便开发人员调查/正确处理/解决方法
 
是指它将返回undefined（这会使我的应用程序内部崩溃）
：您应该记录该方法可能返回undefined
，并且调用它的代码应该能够处理该问题。同样，同事的空对象可能会导致调用代码的异常。最主要的是记录在错误状态下返回的内容，并让您的调用者决定要做什么。不，您不会使用
finally
为错误案例返回默认值。@Bergi对于应该执行的事情，无论在
try
或
catch
中发生什么，
finally
@josepl的实用程序是什么。您通常不希望总是从那里返回
。最突出的用例是关闭资源。@Bergi true，我只是忘记了什么是
最后的
好的，如果由于任何原因在
localStorage
中有一个无效的JSON对象，我将返回一个空对象，假设
getUserFromLocalStorage
将始终工作并返回一些内容（有效），哪个是“不正确的”？既然有错误，我理解你的解释。实际上，如果密钥不存在，我们甚至不应该返回空对象。我想这一切都取决于控制因素