当前位置: 首页 > 知识库问答 >
问题:

抓住被抛弃的人是一种不好的习惯吗?[副本]

司徒良哲
2023-03-14

抓一次性的东西是一种不好的习惯吗?例如,我的代码是这样的。但在声纳中,它表现为虫子。我们如何解决这个问题

try {
            return restTemplate.getForObject(urlSearchID, AccessIDSearchResponse.class);

        } catch (HttpServerErrorException hse) {
            AccesIdExceptionUtility.recoverFromHttpServerExc(hse);
        } catch (HttpClientErrorException hce) {
            AccesIdExceptionUtility.recoverFromHttpClientExc(hce);
        } catch (ClientException ce) {
            AccesIdExceptionUtility.recoverFromClientExc(ce);
        } catch (Exception e) {
            AccesIdExceptionUtility.recoverFromException(e);
        }
        catch (Throwable ex) {
            throw new ServiceException(ErrorMessages.EPO_SYSTEM_ERROR, ex.getMessage(), agentSearchUrl);
        }
        return null;

共有2个答案

和选
2023-03-14

是的,这是个糟糕的练习。在Java中,Throwable是错误和异常的基类。您已经熟悉异常,它们可以被检查或取消检查,因此您可以捕获它们并处理、记录或重新显示。

错误更复杂,它们是JVM的eroror,就像是虚拟机器错误。你打算怎么处理你的代码?答案是:你根本不能。

如果您搜索“可恢复和不可恢复的情况”,异常是可恢复的情况,因为您可以处理NullPointerException,而不可恢复的情况是错误。

如果你想查看Baeldung,这是一个非常好的关于Java、Spring等的博客。https://www.baeldung.com/java-catch-throwable-bad-practice

傅博容
2023-03-14

是的,一般来说,这是个坏主意。

您正在捕获错误和异常。你几乎肯定没有正确地处理它们。例如,根据我对文档的阅读,您错误地处理了ThreadDeath。你在VirtualMachineError上做任何有用的事情的机会都微乎其微。

由于恢复不太可能,其结果是您将混淆原始问题,使调试过程更加困难。

 类似资料:
  • 问题内容: 关于Javadoc的内容不多。(简而言之:它返回字符串的规范表示形式,从而允许使用来比较内部字符串==) 我什么时候可以使用此功能? 是否存在Javadoc中未提及的副作用,即JIT编译器或多或少的优化? 还有其他用途吗? 问题答案: 我何时会使用此函数来支持String.equals() 当你需要速度时,因为可以按引用比较字符串(==比等于快) 是否有Javadoc中未提及的副作用?

  • 问题内容: 该方案。我在写与游戏相关的代码。在该游戏中,(同时也是一个类)具有的列表。有迹象表明,从继承其他类型的项目,例如,或。 显然,拥有我很方便。但是,当我获得玩家物品时,我唯一可以区分哪种物品的方法就是使用关键字。我确信我已经读过,依赖它是不好的做法。 在这种情况下可以使用吗?还是我应该重新考虑我的所有结构? 问题答案: 假设我正在写一些库存代码: 这样可以编译并正常工作。但是它错过了面向

  • 问题内容: 在企业应用程序中使用MS SQL Identity是否是好的做法?在创建业务逻辑以及将数据库从一个迁移到另一个时,难道不是很困难吗? 问题答案: 是的,它们工作得很好,可靠,性能最佳。与不使用身份字段相比,使用身份字段的一大好处是它们可以处理多个调用方尝试保留新ID的所有复杂的并发问题。这看起来似乎是微不足道的代码,但事实并非如此。 以下这些链接提供了一些有关身份字段以及为什么应尽可能

  • 问题内容: 我有一个枚举: 使用方法检查枚举成员之间的“层次结构” 是否存在问题?我的意思是-使用它时,除了冗长之外,还有什么缺点吗?将来有人可能会意外更改顺序。 还是做这样的事更好: 问题答案: TLDR:不,您不应该! 如果您参考javadoc中的方法: 大多数程序员都不会使用这种方法。它设计用于复杂的基于枚举的数据结构,例如和。 首先-阅读手册(在这种情况下为javadoc)。 其次-不要编

  • 问题内容: 我发现了这种模式(或反模式),对此我感到非常满意。 我觉得它非常敏捷: 有时我用它的表弟: 我不需要创建人为的元组并计算参数并将%s匹配位置保留在元组中。 你喜欢它吗?您会/会使用它吗?是/否,请解释。 问题答案: 对于小型应用程序和所谓的“一次性”脚本,这是可以的,尤其是@ kaizer.se提到的增强功能和@RedGlyph提到的版本。 但是,对于维护寿命长且维护人员众多的大型应用

  • 问题内容: 我知道关键字存在于Java中。但是我不记得看到使用它的代码。可能我正在使用异常,并在本可以使用的地方登录。在Java中使用关键字是否是一种好习惯? 编辑 :我知道断言通常是一个好习惯。我的问题是,更准确地说,如果在Java中断言的BKM是使用关键字而不是使用异常,日志记录和其他技术。 问题答案: 不使用断言的主要原因是因为默认情况下未启用断言。因此,如果您的条件足够重要而需要断言,则不