什么'；s是无法处理的异常的定义/示例(框架异常之外)

处理（对我来说）意味着采取适当的操作来恢复应用程序的流程。如果你重新抛出异常，那么你还没有处理它。日志记录是你可能重新抛出异常的一种情况。

可以处理的异常示例：您正在运行一个向特定用户通知事件的服务。你试图使用网络服务发送短信，这会产生一个异常（服务器关闭、帐户关闭等），所以作为后备，你发送了一封电子邮件，但由于另一个异常而失败，所以你只能尝试拨打语音电话。成功了，您的客户会得到他想知道的任何信息的通知。

一个有时可以处理，有时不可以处理的异常示例：您得到一个系统内存不足异常。有时你知道你锁定了一个大型但非关键的东西，你可以释放它，然后重试，但通常你有活动引用的所有东西都是必须的，在这种情况下，你真的无法恢复。

请注意，通常情况下，处理意味着对被要求执行某些操作并返回成功/失败的函数只返回false。这并不像最初看起来那么无用，考虑一下这种情况：对文件进行更改，然后告诉应用程序保存更改。磁盘已满或由于某种原因不可用。任何一种都将导致异常。当保存isDirty=savefile（）时，异常发生在savefile内部，并由savefile通过将结果设置为false来"处理"。这允许应用程序知道（并向用户显示）文件尚未保存。

除了CLR无法捕获的关键框架异常（StackOverflow、OutOfMemory等）之外，还有一些异常通常不应该被捕获，因为它们代表了开发人员在开发过程中应该解决的错误。虽然记录异常可以被视为一种"处理"异常的机制，但只有在检查日志文件中的错误时，它才有用。

一般来说，像ArgumentNullException、ArgumentException、NullReferenceException等异常不应该被开发人员明确捕获，并且应该允许它们冒泡，以便可以识别和修复它们。