blocks|key|1449043|text|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1449044|只有在您能够以有意义的方式处理异常时才能捕获它|unordered-list-item|1449045|声明向上抛出异常如果异常由当前方法的使用者处理|1449046|抛出异常如果异常是由输入参数引起的(但这些异常通常是未检查的)|1449047|1449048|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|-4|4|5|6|K|7|@]|8|@]|9|$]]|$1|A|3|B|4|C|6|L|7|@]|8|@]|9|$]]|$1|D|3|E|4|C|6|M|7|@]|8|@]|9|$]]|$1|F|3|G|4|C|6|N|7|@]|8|@]|9|$]]|$1|H|3|-4|4|5|6|O|7|@]|8|@]|9|$]]|$1|I|3|-4|4|5|6|P|7|@]|8|@]|9|$]]]|J|$]]

<ul>
<li>catch an exception only if you can handle it in a meaningful way</li>
<li>declare throwing the exception upward if it is to be handled by the consumer of the current method</li>
<li>throw exceptions if they are caused by the input parameters (but these are more often unchecked)</li>
</ul>

blocks|key|3782294|text|通常，当一个方法不能在本地处理相关的问题时，它应该向它的调用者抛出一个异常。例如，如果假设该方法从具有给定路径的文件中读取数据，则无法以合理的方式在本地处理IOExceptions。这同样适用于无效输入，并补充说，我个人的选择是抛出一个未经检查的异常，比如本例中的IllegalArgumentException。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|3782295|如果出现以下情况，它应该从被调用的方法中捕获异常：|3782296|3782297|它是可以在本地处理的东西(例如，尝试将输入字符串转换为数字，如果转换失败，则返回默认值是完全有效的)，|unordered-list-item|3782298|或它不应该被抛出(例如，如果异常来自特定于实现的较低层，其实现细节不应该对调用者可见-例如，我不想显示我的DAO使用Hibernate来持久化我的实体，因此我在本地捕获所有HibernateExceptions并将它们转换为我自己的异常类型)。|3782299|3782300|entityMap^0|26|C|3O|O|0|0|0|0|1H|3|1M|9|2E|J|0|0^^$0|@$1|2|3|4|5|6|7|Q|8|@$9|R|A|S|B|C]|$9|T|A|U|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|V|8|@]|D|@]|E|$]]|$1|H|3|-4|5|6|7|W|8|@]|D|@]|E|$]]|$1|I|3|J|5|K|7|X|8|@]|D|@]|E|$]]|$1|L|3|M|5|K|7|Y|8|@$9|Z|A|10|B|C]|$9|11|A|12|B|C]|$9|13|A|14|B|C]]|D|@]|E|$]]|$1|N|3|-4|5|6|7|15|8|@]|D|@]|E|$]]|$1|O|3|-4|5|6|7|16|8|@]|D|@]|E|$]]]|P|$]]

In general, a method should throw an exception to its caller when it can't handle the associated problem locally. E.g. if the method is supposed to read from a file with the given path, <code>IOExceptions</code> can't be handled locally in a sensible way. Same applies for invalid input, adding that my personal choice would be to throw an unchecked exception like <code>IllegalArgumentException</code> in this case.

And it should catch an exception from a called method it if:

<ul>
<li>it is something that can be handled locally (e.g. trying to convert an input string to a number, and if the conversion fails, it is entirely valid to return a default value instead),</li>
<li>or it should not be thrown (e.g. if the exception is coming from an implementation-specific lower layer, whose implementation details should not be visible to the caller — for example I don't want to show that my <code>DAO</code> uses <code>Hibernate</code> for persisting my entities, so I catch all <code>HibernateExceptions</code> locally and convert them into my own exception types).</li>
</ul>

blocks|key|705680|text|下面是我使用它的方法：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|705681|抛出：|offset|length|style|BOLD|705682|705683|您只希望代码在发生错误时停止。|unordered-list-item|705684|适用于在不满足某些先决条件的情况下容易出错的方法。|705685|705686|捕获Try-：|705687|如果您想要向最终用户提供有意义的错误，则可以使用不同的errors.|705688|Great使程序的行为有所不同。|705689|。|705690|705691|705692|我知道很多人总是使用投掷，因为它更干净，但几乎没有那么多的控制力。|705693|entityMap^0|0|0|3|0|0|0|0|0|6|1|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|12|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|13|8|@$D|14|E|15|F|G]]|9|@]|A|$]]|$1|H|3|-4|5|6|7|16|8|@]|9|@]|A|$]]|$1|I|3|J|5|K|7|17|8|@]|9|@]|A|$]]|$1|L|3|M|5|K|7|18|8|@]|9|@]|A|$]]|$1|N|3|-4|5|6|7|19|8|@]|9|@]|A|$]]|$1|O|3|P|5|6|7|1A|8|@$D|1B|E|1C|F|G]]|9|@]|A|$]]|$1|Q|3|R|5|6|7|1D|8|@]|9|@]|A|$]]|$1|S|3|T|5|K|7|1E|8|@]|9|@]|A|$]]|$1|U|3|V|5|K|7|1F|8|@]|9|@]|A|$]]|$1|W|3|-4|5|6|7|1G|8|@]|9|@]|A|$]]|$1|X|3|-4|5|6|7|1H|8|@]|9|@]|A|$]]|$1|Y|3|Z|5|6|7|1I|8|@]|9|@]|A|$]]|$1|10|3|-4|5|6|7|1J|8|@]|9|@]|A|$]]]|11|$]]

Here's the way I use it:

Throws: 

<ul>
<li>You just want the code to stop when
an error occurs.</li>
<li>Good with methods that are prone to
errors if certain prerequisites are
not met.</li>
</ul>

Try-Catch: 

<ul>
<li>When you want to have the program
behave differently with different
errors.</li>
<li>Great if you want to provide
meaningful errors to end users.</li>
</ul>

I know a lot of people who always use Throws because it's cleaner, but there's just not nearly as much control.

blocks|key|2374597|text|我个人的经验法则很简单：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2374598|2374599|我能以有意义的方式处理它吗(从评论中添加)？因此，将代码放在try/catch中。通过处理它，我的意思是能够通知用户/从错误中恢复，或者，在更广泛的意义上，能够理解这个异常如何影响我的code.|unordered-list-item|offset|length|style|CODE|2374600|Elsewhere，的执行丢弃它|2374601|2374602|注意:此回复现在是一个社区维基，请随时在中添加更多信息。|2374603|entityMap^0|0|0|U|9|0|0|0|0^^$0|@$1|2|3|4|5|6|7|Q|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|R|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|S|8|@$F|T|G|U|H|I]]|9|@]|A|$]]|$1|J|3|K|5|E|7|V|8|@]|9|@]|A|$]]|$1|L|3|-4|5|6|7|W|8|@]|9|@]|A|$]]|$1|M|3|N|5|6|7|X|8|@]|9|@]|A|$]]|$1|O|3|-4|5|6|7|Y|8|@]|9|@]|A|$]]]|P|$]]

My personnal rule of thumb for that is simple :

<ul>
<li>Can I handle it in a meaningful way (added from comment)? So put code in <code>try/catch</code>. By handle it, I mean be able to inform the user/recover from error or, in a broader sense, be able to understand how this exception affects the execution of my code.</li>
<li>Elsewhere, throw it away</li>
</ul>

Note : this replys is now a community wiki, feel free to add more info in.

blocks|key|3782505|text|向你的方法添加try-catch或throws子句的决定取决于“你想(或有)如何处理你的异常”。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3782506|如何处理异常是一个广泛且远非微不足道的问题。它特别涉及到在哪里处理异常以及在catch块中实现哪些操作的决定。事实上，如何处理异常应该是一个全局的设计决策。|3782507|因此，在回答你的问题时，没有经验法则。|3782508|您必须决定在哪里处理您的异常，而这个决定通常非常特定于您的域和应用程序需求。|3782509|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

The decision to add a try-catch or a throws clause to your methods depends on "how you want (or have) to handle your exception".

How to handle an exception is a wide and far from trivial question to answer. It involves specially the decision of where to handle the exception and what actions to implement within the catch block. In fact, how to handle an exception should be a global design decision.

So answering your questions, there is no rule of thumb.

You have to decide where you want to handle your exception and that decision is usually very specific to your domain and application requirements.

blocks|key|2374660|text|如果引发异常的方法有足够的信息来处理它，那么它应该捕获并生成关于发生了什么以及正在处理哪些数据的有用信息。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2374661|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

If the method where the exception got raised has a sufficent amount of information to deal with it then it should catch, generate useful information about what happened and what data was being processed.

blocks|key|2374865|text|只有当方法能够合理地保证对象的状态、传递给该方法的任何参数以及该方法所作用的任何其他对象时，该方法才应该throws异常。例如，一个应该从集合中检索调用者期望包含在其中的项的方法可能会throws一个检查的异常，如果期望存在于集合中的项不存在，则捕获该异常的调用者应该期望集合不包含有问题的项。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|2374866|请注意，虽然Java将允许检查异常通过声明为抛出适当类型的异常的方法冒泡，但这种使用通常应被视为反模式。例如，假设某个方法LookAtSky()被声明为调用FullMoonException，并且被期望在月圆时抛出它；再想象一下，LookAtSky()调用ExamineJupiter()，它也被声明为throws+FullMoonException。如果FullMoonException是由ExamineJupiter()抛出的，并且如果LookAtSky()没有捕获它并处理它，或者将它包装在其他异常类型中，那么调用LookAtSky的代码将假定该异常是由于地球的月亮是满的；它不会知道木星的某个卫星可能是罪魁祸首。|2374867|只有当异常对方法的调用者意味着与对被调用的方法意味着相同的事情时，才应该允许调用者期望处理的异常(基本上包括所有检查过的异常)通过方法向上渗透。如果代码调用的方法被声明为抛出某个已检查的异常，但调用者并不希望它在实践中抛出该异常(例如，因为它认为它预先验证了方法参数)，则应该捕获已检查的异常并将其包装在某个未检查的异常类型中。如果调用者不希望异常被抛出，那么调用者就不能期望它有任何特殊的含义。|2374868|entityMap^0|1G|6|2K|6|0|1P|B|26|H|37|B|3K|G|47|O|4Y|H|5H|G|65|B|79|9|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@$9|M|A|N|B|C]|$9|O|A|P|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|Q|8|@$9|R|A|S|B|C]|$9|T|A|U|B|C]|$9|V|A|W|B|C]|$9|X|A|Y|B|C]|$9|Z|A|10|B|C]|$9|11|A|12|B|C]|$9|13|A|14|B|C]|$9|15|A|16|B|C]|$9|17|A|18|B|C]]|D|@]|E|$]]|$1|H|3|I|5|6|7|19|8|@]|D|@]|E|$]]|$1|J|3|-4|5|6|7|1A|8|@]|D|@]|E|$]]]|K|$]]

A method should only <code>throws</code> an exception if it can make reasonable guarantees surrounding the state of the object, any parameters passed to the method, and any other objects the method acts upon. For example, a method which is supposed to retrieve from a collection an item which the caller expects to be contained therein might <code>throws</code> a checked exception if the item which was expected to exist in the collection, doesn't. A caller which catches that exception should expect that the collection does not contain the item in question.

Note that while Java will allow checked exceptions to bubble up through a method which is declared as throwing exceptions of the appropriate types, such usage should generally be considered an anti-pattern. Imagine, for example, that some method <code>LookAtSky()</code> is declared as calling <code>FullMoonException</code>, and is expected to throw it when the Moon is full; imagine further, that <code>LookAtSky()</code> calls <code>ExamineJupiter()</code>, which is also declared as <code>throws FullMoonException</code>. If a <code>FullMoonException</code> were thrown by <code>ExamineJupiter()</code>, and if <code>LookAtSky()</code> didn't catch it and either handle it or wrap it in some other exception type, the code which called <code>LookAtSky</code> would assume the exception was a result of Earth's moon being full; it would have no clue that one of Jupiter's moons might be the culprit.

Exceptions which a caller may expect to handle (including essentially all checked exceptions) should only be allowed to percolate up through a method if the exception will mean the same thing to the method's caller as it meant to the called method. If code calls a method which is declared as throwing some checked exception, but the caller isn't expecting it to ever throw that exception in practice (e.g. because it thinks it pre-validated method arguments), the checked exception should be caught and wrapped in some unchecked exception type. If the caller isn't expecting the exception to be thrown, the caller can't be expecting it to have any particular meaning.

blocks|key|2374998|text|什么时候用什么。关于这一点我搜索了很多。没有硬性规定。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2374999|“但是作为开发人员，检查过的异常必须包含在方法的throws子句中。这对于编译器知道要检查哪些异常是必要的。按照惯例，未检查的异常不应该包含在throws子句中。|2375000|包含它们被认为是糟糕的编程实践。编译器将它们视为注释，并且不对它们进行检查。|2375001|资料来源：《SCJP+6》一书，作者:凯西·塞拉|2375002|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

When to use what. I searched a lot about this. 
There is no hard and fast rule. 

"But As a developer, Checked exceptions must be included in a throws clause of the method. This is necessary for the compiler to know which exceptions to check.
By convention, unchecked exceptions should not be included in a throws clause. 
Including them is considered to be poor programming practice. The compiler treats them as comments, and does no checking on them."

Source : SCJP 6 book by Kathy Sierra

blocks|key|704044|text|我将使它变得简单。当您认为被调用的方法不是异常的原因时(例如，来自调用者方法的无效参数、要搜索的项、在集合或fetch+datalist中不可用的fetch)，请使用throws。当您认为被调用方法中的功能可能会导致某些异常时，请使用try+catch块(处理被调用方法中的异常|type|unstyled|depth|inlineStyleRanges|entityRanges|data|704045|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

I ll make it simple for you.
Use throws when you think that the called method is not responsible for the exception (e.g., Invalid parameters from the caller method, item to be searched, fetched not available in the collections or fetch datalist).
Use try catch block(handle the exception in the called method) when you think that your functionality in the called method may result in some exception

blocks|key|3782706|text|如果使用try+catch，则在发生异常时，仍将执行其余代码。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3782707|如果您指定抛出异常的方法，那么当异常发生时，代码将立即停止执行。|3782708|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

If you use a try catch, when the exception occurs, the remaining codes would be still executed.

If you indicate the method to throw the exception, then when the exception occurs, the code would stop being executed right away.

blocks|key|3782747|text|当您希望提供自定义行为时，可使用try-catch对，以防exception+occurs.....in+other+words...you根据您的程序要求提供问题的解决方案(异常发生).....|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3782748|但是当你没有任何关于异常发生的具体解决方案时，就会使用抛出。case...you只是不想让你的程序异常终止。|3782749|希望它是正确的:-)|3782750|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

try-catch pair is used when you want to provide customise behaviour, in case if exception occurs.....in other words...you have a solution of your problem (exception occurrence) as per your programme requirements.....

But throws is used when you don't have any specific solution regarding the exception occurrence case...you just don't want to get abnormal termination of your programme....

Hope it is correct :-)

What is the general rule of thumb when deciding whether to add a <code>throws</code> clause to a method or using a <code>try-catch</code>?

From what I've read myself, the <code>throws</code> should be used when the caller has broken their end of the contract (passed object) and the <code>try-catch</code> should be used when an exception takes place during an operation that is being carried out inside the method. Is this correct? If so, what should be done on the callers side?

P.S: Searched through Google and SO but would like a clear answer on this one.

Throws or try-catch

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云AI代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

功能1上新10个字符

功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符。

功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符。

功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符

功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符

功能4上新

文章&问答评论现已支持表情

全新交互，全新视觉，新增快捷键、悬浮工具栏、高亮块等功能并同时优化现有功能，全面提升创作效率和体验

社区富文本编辑器全新改版！诚邀体验～ 

精选全网热门MCP server，让你的AI更好用 🚀

💥开发者 MCP广场重磅上线！

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

在决定是向方法添加throws子句还是使用try-catch时，一般的经验法则是什么据我所知，throws应该在调用者违反约定(传递的对象)时使用，而try-catch应该在方法内部执行的操作过程中发生异常时使用。这是正确的吗？如果是这样的话，调用方应该做些什么？附言:通过谷歌搜索过了，所以我想要一个明确的答案。

问抛出或try-catch
EN

回答 11

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问抛出或try-catchEN

回答 11

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问抛出或try-catch
EN