首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往

如何避免滥用TRY,除非需要检查API参数?

TRY语句是一种异常处理机制,用于捕获和处理可能发生的异常。它的作用是在代码执行过程中,当发生异常时,可以通过TRY语句块中的代码来捕获并处理异常,从而避免程序的崩溃或异常退出。

然而,滥用TRY语句可能会导致代码的可读性和性能下降,因此在编写代码时需要谨慎使用。以下是一些避免滥用TRY语句的方法:

  1. 预防性编程:在编写代码时,尽量避免可能引发异常的情况,例如对输入进行合法性验证、使用条件语句进行判断等。这样可以减少TRY语句的使用频率。
  2. 使用合适的异常处理策略:根据具体的业务需求和异常类型,选择合适的异常处理策略。有些异常可以通过代码逻辑进行处理,而不需要使用TRY语句捕获和处理。
  3. 尽早捕获异常:在代码中,尽量将TRY语句放置在可能引发异常的代码块之前,以便尽早捕获异常并进行处理。这样可以减少TRY语句的嵌套层级,提高代码的可读性。
  4. 避免捕获过于宽泛的异常:TRY语句应该尽量只捕获需要处理的异常,而不是捕获所有可能的异常。捕获过于宽泛的异常可能会隐藏真正的问题,导致难以定位和修复。
  5. 使用其他合适的错误处理机制:除了TRY语句,还可以使用其他合适的错误处理机制,例如条件语句、断言、日志记录等。根据具体情况选择合适的机制,以提高代码的可读性和性能。

需要注意的是,TRY语句的滥用可能会导致代码的可读性和性能下降,因此在使用TRY语句时需要权衡利弊,并根据具体情况进行合理的使用和处理。

页面内容是否对你有帮助?
有帮助
没帮助

相关·内容

不要再滥用可选链运算符(?.)啦!

维护开发追踪问题看到这行代码,data items 这些属性肯定不能是空值,不然console就抛错了,但是bug现象里并没有抛错,所以只需要检查user能不能是空值就行了,很容易就排除了很多情况。...其实这种现象跟 try catch 里不加 throw 类似,把隐式异常错误完全给过滤掉了,比如下面例子: // 这个try本意是处理api请求异常 try { const data = getSaveData...() // 这段js逻辑也在try里,所以如果这个方法内部抛错了,页面上就没任何反应,很难追踪问题 const result = await api.post(url, data) //...当然不是不能用,这个特性对于开发肯定好处很多的,但是得合理用,不能滥用避免盲目用,滥用,有个点儿就加问号,特别是在一个比较长的链式代码里每个属性后面都加。...“正确用法”: 避免盲目用,滥用,有个点儿就加问号,特别是在一个比较长的链式代码里每个属性后面都加。 只有可能是空值,而且业务逻辑中有空值的情况,就用;其它情况尽量不要用。

32020

不要再滥用可选链运算符(?.)啦!

维护开发追踪问题看到这行代码,data items 这些属性肯定不能是空值,不然console就抛错了,但是bug现象里并没有抛错,所以只需要检查user能不能是空值就行了,很容易就排除了很多情况。...其实这种现象跟 try catch 里不加 throw 类似,把隐式异常错误完全给过滤掉了,比如下面例子: // 这个try本意是处理api请求异常 try { const data = getSaveData...() // 这段js逻辑也在try里,所以如果这个方法内部抛错了,页面上就没任何反应,很难追踪问题 const result = await api.post(url, data) //...当然不是不能用,这个特性对于开发肯定好处很多的,但是得合理用,不能滥用避免盲目用,滥用,有个点儿就加问号,特别是在一个比较长的链式代码里每个属性后面都加。...“正确用法”: 避免盲目用,滥用,有个点儿就加问号,特别是在一个比较长的链式代码里每个属性后面都加。 只有可能是空值,而且业务逻辑中有空值的情况,就用;其它情况尽量不要用。

38540
  • 如何保护 Windows RPC 服务器,以及如何不保护。

    虽然有很多关于如何滥用 EFSRPC 接口的详细信息,但对于为什么它可以被利用的原因却很少。...服务器可以做的其他检查是客户端使用的协议序列,这将允许通过 TCP 拒绝访问但允许命名管道。 最后一个参数是标志。...临时安全 最后的检查类型基本上是服务器为验证调用者所做的任何其他事情。一种常见的方法是在接口上的特定功能内执行检查。例如,服务器通常可以允许未经身份验证的客户端,除非调用方法来读取重要的秘密值。...深入研究 EFSRPC 好的,这涵盖了如何保护 RPC 服务器的基础知识。下面看一下 PetitPotam 滥用的 EFSRPC 服务器的具体例子。...这个博客的重点不是滥用 EFSRPC,而是为什么它是可滥用的 :-)

    3.1K20

    【面试题精讲】常见的非受检异常

    检查输入参数:在方法内部进行参数校验,确保传入的参数是合法的,避免抛出 IllegalArgumentException 等异常。...异常捕获和处理:对于无法避免的非受检异常,可以使用 try-catch 语句捕获并处理异常。但需要注意,在捕获异常后要采取适当的措施,例如记录日志、回滚事务等。 4....使用非受检异常的注意事项 在使用非受检异常时,需要注意以下几点: 不要滥用非受检异常:只有在遇到无法恢复的错误或者确信不会被捕获和处理时才使用非受检异常。...非受检异常通常由程序错误、逻辑错误或运行时环境导致,可以通过避免出现异常、检查输入参数、使用条件判断和异常捕获来处理。...在使用非受检异常时,需要注意不要滥用异常、良好的异常命名和捕获处理异常。

    30540

    Effective-java-读书笔记之方法

    第49条 检查参数的有效性方法的参数限制, 应该在文档中指明, 并且在方法体的开头处检查参数, 以强制施加这些限制.对于公有的方法, 要用Javadoc的@throws标签在文档中说明违反参数值限制时会抛出的异常...避免过长的参数列表. -> 1.分解成多个方法; 2.创建辅助类, 用来保存参数的分组; 3.从对象构建到方法调用都采用Builder模式.参数类型优先使用接口而不是类.对于boolean参数, 要优先使用两个元素的枚举类型..., 可变参数是一种很方便的方式, 但是它们不应该被过度滥用.第54条 返回零长度的数组或集合, 而不是null返回类型为数组或集合的方法, 应该返回一个零长度的数组或者集合, 没理由返回null. ->...这个约定应该说明这个方法做了什么, 而不是如何完成这项工作的.方法的文档注释还应该列举出:所有前提条件....偶尔你需要用{@index}加入额外的index.泛型, 枚举, 注解都需要额外的注意: 当为泛型方法写文档时, 需要为每个泛型参数写文档注释.枚举需要为每个常量写注释.注解需要注释每个成员.

    43150

    效率编程 之「异常」

    Java 平台类库提供了一组基本的未受检的异常,它们满足了绝大多数 API 的异常抛出需要。因此,我们应该优先使用标准异常。...为了避免这个问题,更高层的实现应该捕获底层的异常,同时抛出可以按照高层抽象进行解释的异常。...尽管异常转译与不加选择地从底层传递异常的做法相比有所改进,但是它也不能被滥用。...最简单的方法莫过于设计一个不可变的对象,如果一个操作失败了,它可能会阻止创建新的对象,但是永远也不会使已有的对象保持在不一致的状态之中;对于在可变对象上执行操作的方法,获得失败原子性最常见的方法是,在执行操作之前检查参数的有效性...如果对参数检查只有在执行了部分计算之后才能进行,这种办法实际上就是上一种办法的自然扩展。

    58030

    Effective-java-读书笔记之创建和销毁对象

    适用于基于接口的框架, 可以隐藏实现类API, 也可以根据参数返回不同的子类型.由于在Java 8之前, 接口不能有静态方法, 因此按照惯例, 接口Type的静态工厂方法被放在一个名为Types的不可实例化的类中...返回对象的类型可以根据输入的参数而变化. 比如EnumSet类的静态工厂, 根据元素的多少返回不同的子类型.返回对象的类型不需要在写这个方法的时候就存在....子类build()方法返回自己的类型(covariant return typing).Builder模式的优势: 可读性增强; 可以有多个可变参数; 易于做参数检查和构造约束检查; 比JavaBeans...通过私有构造器强化不可实例化的能力只包含静态方法和静态域的类名声不太好, 因为有些人会滥用它们来编写过程化的程序....内存), 除非池中的对象是非常重量级的.

    39100

    关于防御式编程的一点思考

    保护数据免遭非法数据的破坏 检查所有外部输入的数据,包括外部文件,读取的用户输入等 检查子程序的输入参数 决定如何处理错误的输入数据 防御式编程的理念就是在一开始就不要引入错误。...在碰到错误后,如何处理呢? 返回中立的值。在某些场景下是很有用的,在Java中可以直接用 Optional类的API来做相关处理 换用下一个正确的数据。...异常 异常也是我们工具箱中一个有力的工具,但是不能滥用异常,需要审慎明智的使用。 用异常通知程序的其他部分,发生了不可忽略的错误。 只有在真正例外情况下才抛出异常。 不能用异常来推卸责任。...避免在构造函数和析构函数中抛出异常,除非在同一地方将其捕获。 在恰当的抽象层次抛出异常。...异常在有些时候可以简化很多需要处理的流程,但我们还是需要根据上面的这些原则来谨慎的使用异常。 对防御式编程保持防御姿态 不要过度防御,过多的检查会使得项目变得臃肿,主线处理逻辑不清晰。

    1.2K30

    Vue 文档编写指南

    这份不断发展的指南提供了一些规则和建议,说明如何在 Vue 生态系统中始终如一地做到这一点。 原则 除非有充分的文档证明,否则功能不存在。 尊重用户的认知能力 (即脑力)。...Essentials 可以链接到更高阶的指南和 API,不过,在大多数情况下,你应该避免此类链接。当它们被提供时,你还需要提供一个上下文,以便用户知道他们是否应该在第一次阅读时遵循这个链接。...最后 5%的用例是更利基的、更复杂的和/或更容易被滥用的,将留给烹饪书和 API 参考,它们可以从这些高阶指南链接到。...在内容上有些重复是不可避免的,甚至是学习的必要条件。然而,过多的重复也会使文档更难维护,因为 API 的更改将需要在许多地方进行更改,而且很容易遗漏某些内容。这是一个很难达到的平衡。...语法 避免缩写在编写代码和示例代码中 (例如,attribute 优于 attr,message 优于 msg),除非你在 API 中明确引用了缩写 (例如 $attrs)。

    67920

    C++异常处理深度探索:从基础概念到高级实践策略

    本文将从C++异常处理的基本概念出发,逐步介绍如何定义和抛出异常、如何捕获和处理异常,以及如何在复杂项目中有效运用异常处理机制。...在检查函数返回值后,可以检查errno来获取更具体的错误信息。...以下是如何自定义异常体系的一些步骤和示例: 4.1 定义异常类 首先,你需要定义一个新的异常类。...异常安全性:在构造函数、析构函数或资源管理类(如RAII类)中避免抛出异常,除非你有特别的理由并且知道如何处理它。 错误消息:提供清晰、有用的错误消息,以帮助调试和诊断问题。...在C++等语言中,合理使用异常可以提高代码的健壮性和可维护性,但也需要注意避免滥用和性能问题。

    14910

    Java异常Error和Exception的区别「建议收藏」

    检查异常就是所谓的运行时异常,类似 NullPointerException、ArrayIndexOutOfBoundsException 之类,通常是可以编码避免的逻辑错误,具体根据需要来判断是否需要捕获...要理解Java异常处理是如何工作的,你需要掌握以下三种类型的异常: 检查性异常:(非运行时异常)最具代表的检查性异常是用户错误或问题引起的异常,这是程序员无法预见的。...运行时异常: 运行时异常是可能被程序员避免的异常。与检查性异常相反,运行时异常可以在编译时被忽略。 错误: 错误不是异常,而是脱离程序员控制的问题。错误在代码中通常被忽略。...2、Java语言如何进行异常处理,关键字:throws、throw、try、catch、finally分别如何使用?...异常和继承一样,是面向对象程序设计中经常被滥用的东西,在Effective Java中对异常的使用给出了以下指导原则: 不要将异常处理用于正常的控制流(设计良好的API不应该强迫它的调用者为了正常的控制流而使用异常

    1.7K10

    Golang深入浅出之-Go语言中的反射(reflect):原理与实战应用

    在Go语言中,反射(Reflection)允许程序在运行时检查和修改自身的结构,它是一种强大的工具,但也容易滥用。...避免方法:只有在确实需要动态操作类型或值时才使用反射,尽量保持代码的静态类型。易错点二:无法进行类型检查反射不能像常规类型那样进行类型检查,可能导致运行时错误。...避免方法:在使用反射前,先通过Kind()方法检查类型,确保安全。易错点三:修改不可导出字段反射可以访问不可导出字段,但这样做可能导致封装破坏。...避免方法:除非必要,否则避免修改不可导出字段,尊重封装原则。实战应用动态接口实现反射可以用于创建动态实现接口的对象,这对于插件系统或动态数据处理很有用。...理解反射的原理,明确其在何时何地能带来价值,以及如何避免潜在问题,是每个Go程序员的必修课。在实际应用中,我们应尽量保持代码的静态类型,只在必要时才使用反射,以保持代码的清晰和高效。

    1.2K20

    【Java 基础篇】Java 异常处理指南:解密异常处理的关键技巧

    本篇博客将向你介绍 Java 中异常的基础知识,帮助你理解什么是异常、为什么需要异常处理以及如何在代码中处理异常。 什么是异常?...常见的可检查异常包括 IOException、SQLException 等。处理可检查异常的方式通常是使用 try-catch 块来捕获和处理异常。...不可检查异常(Unchecked Exception):也称为运行时异常(RuntimeException),这些异常通常是由程序中的错误或逻辑问题引起的,不需要在代码中显式捕获或处理。...避免不必要的检查异常:不要滥用检查异常。只有在需要时才声明和捕获检查异常。 处理异常的层次:在代码的适当层次进行异常处理,不要让异常传播到不合适的层次。...异常处理示例 以下是一个简单的示例,演示了如何使用 try-catch 块来处理异常: public class ExceptionHandlingExample { public static

    41820

    设计异常解决方案的几点注意事项

    × 不要把异常用作公有成员的返回值或输出参数。 这样会丧失用异常来报告操作失败的诸多好处。 × 避免显式地从finally代码块中抛出异常。...√ 要在进行清理工作时使用try-finally,避免使用try-catch。 对于精心编写的代码来说,try-finally的使用频率要比try-catch要高的多。...这一点可能有违于直觉,因为有时可能会觉得:try不就是为了catch吗?要知道一方面我们要考虑程序状态的一致,另一方面我们还需要考虑资源的清理工作。...× 避免捕获Exception或SystemException类型的异常,除非是在顶层的异常处理器程序中。...7.2 Try-Parse 模式 与Tester-Doer 模式相比,Try-Parse 模式甚至更快,应在那些对性能要求极高的API中使用。

    75290

    恢复 RecyclerView 的滚动位置

    通常这种情况发生的原因是由于异步加载 Adapter 数据,且数据在 RecyclerView 需要进行布局的时候尚未加载完成,导致 RecyclerView 无法恢复到之前的滚动位置。...从  1.2.0-alpha02 版本开始,Jetpack RecyclerView 提供了一个新的 API,可以让 Adapter  在数据加载完成之前阻塞布局行为 ,从而避免丢失滚动位置信息。...接下来我们会介绍如何使用这个新的 API,以及它的工作原理。 恢复至原有滚动位置 有好几种方法可以用来恢复 RecyclerView 至正确的滚动位置,您可能已经在实际项目中用到了这些方法。...),要么会导致 LayoutManager.onRestoreInstanceState API 被滥用。...如果在 Adapter 中有一些默认的 item,比如 header 或是 load progress indicator,那您应该使用 PREVENT 选项,除非是通过 ConcatAdapter 添加默认的

    1.5K10

    项目中的异常处理策略与最佳实践

    今天,我们将深入探讨,在项目开发中,为什么你一定会使用异常处理,以及如何巧妙地运用它,为你的代码赋予更高的稳定性和可维护性。...使用 finally 释放资源 在异常处理中,使用 try-catch-finally 结构,可以确保资源的正确释放。...非检查异常滥用检查异常(Unchecked Exception)通常表示程序内部错误,例如空指针异常。然而,滥用检查异常来处理业务逻辑问题会导致代码难以理解和维护。...应当明确业务逻辑异常与内部错误异常的区别,避免滥用异常。 2. 吞掉异常 有时候,开发者可能会忽略异常,导致异常被“吞掉”而不做处理。这可能掩盖了潜在的问题,导致难以定位和修复。...只捕获需要处理的异常,避免无谓的异常捕获,保持代码的简洁性。 在项目开发中,异常处理是确保代码稳定性、可维护性和用户体验的关键一环。

    54020

    有点长的 Java API 设计清单

    就像飞行员起飞前的检查清单,这张清单将帮助软件设计者在设计Java API的过程中回忆起那些明确的或者不明确的规范。本文也可以看作为“API设计指南”这篇文章的附录。...在API的开始处用一句短小的话来概括(描述) ▲1.3.4. 提供足够多的细节来帮助判断是否需要使用和如何使用该API ▲1.3.5. 指出该API的入口(主要的类或者方法) ▲1.3.6....只需要为可恢复的错误抛出已确认的异常 ▲3.4.3. 为了通知Api使用错误而抛出运行时异常 ▲3.4.4. 在适当的抽象层次抛出异常 ▲3.4.5. 进行运行时预置条件的检查 ▲3.4.6....为一个被不能为null的参数抛出空指针异常 ▲3.4.7. 为一个除为null以外异常值的参数除非参数异常 ▲3.4.8. 为一个错误上下文环境中的方法调用抛出非法状态异常 ▲3.4.9....在错误信息中显示出参数的预置条件 ▲3.4.10. 确保失败的方法调用不会产生单向的后果 ▲3.4.11. 为回调方法中的禁止使用的Api提供运行时检查 ▲3.4.12.

    52010

    打造 API 接口的堡垒

    大家可以通过白名单的方式来严格控制无需授权的 API 接口的访问;除非资源完全对外开放,否则访问默认都要授权,尤其是访问用户的资源或者受限制资源。...如何设计并保证 API 接口安全我相信大家一般不会把大额的钱随身携带。大多数人都会选择把钱存到可信的环境中,在需要支付时采用分开的方式授权和验证支付。...API 安全防护与之相似,所以,我们需要一个具有验证和授权策略的可信环境。接下来,我们来聊聊如何去营造这样的一个环境。...无论是从安全的角度考虑,还是从吊销的角度考虑,Token 都需要设有效期。使用 RefreshToken,它可以避免频繁的读写操作。...五大安全规范能见度作为一名合格的应用程序开发人员和用户,我们需要知道正在发布哪些 API如何以及何时更新它们、谁在访问它们以及如何访问它们。

    53610

    有点长的 Java API 设计清单

    就像飞行员起飞前的检查清单,这张清单将帮助软件设计者在设计Java API的过程中回忆起那些明确的或者不明确的规范。本文也可以看作为“API设计指南”这篇文章的附录。...在API的开始处用一句短小的话来概括(描述) ▲1.3.4. 提供足够多的细节来帮助判断是否需要使用和如何使用该API ▲1.3.5. 指出该API的入口(主要的类或者方法) ▲1.3.6....只需要为可恢复的错误抛出已确认的异常 ▲3.4.3. 为了通知Api使用错误而抛出运行时异常 ▲3.4.4. 在适当的抽象层次抛出异常 ▲3.4.5. 进行运行时预置条件的检查 ▲3.4.6....为一个被不能为null的参数抛出空指针异常 ▲3.4.7. 为一个除为null以外异常值的参数除非参数异常 ▲3.4.8. 为一个错误上下文环境中的方法调用抛出非法状态异常 ▲3.4.9....在错误信息中显示出参数的预置条件 ▲3.4.10. 确保失败的方法调用不会产生单向的后果 ▲3.4.11. 为回调方法中的禁止使用的Api提供运行时检查 ▲3.4.12.

    82530

    框架设计原则和规范(三)

    避免在对性能要求很高的API中使用回调函数 1.1.3.5. 要在定义用了回调函数的API时,使用新的Func,Action或Expression<......抽象需要考虑是用类还是接口表达,前面有专门章节讨论 1.1.5.1. 除非为该抽象开发出多个具体实现,并且通过用到该抽象的API对其进行过实际测试,否则不要提供抽象 1.1.5.2....避免在命名基类时使用“Base”后缀——如果公共API中会用到这个类 有些基类还是会被框架暴露的API所用到,而不是子类,增加后缀只会对使用该方法的用户造成不必要的干扰 1.3....除非有恰当理由,不要把类密封起来: l 静态类可以 l 类的受保护成员保存了需要高度保密的机密信息 l 类继承了许多成员,分别密封那些成员太麻烦,不如整个类密封 l 类是修饰属性(Attribute),...避免捕获Exception或SystemException异常,除非是在顶层的异常处理器中 2.3.2.

    99260
    领券