如果在Java代码中调用以下方法，则会对IOException发出警告，但会忽略Kotlin中的任何警告，因为IOException是已检查的异常。
ParcelFileDescriptor.open(file, ParcelFileDescriptor.MODE_READ_WRITE)
Java强制开发人员在抛出异常时采取安全的操作，但在Kotlin中，它只是忽略了创建潜在错误源的异常。我敢肯定，有很多类似的情况下，检查异常被简单地忽略了。
问题是如何处理此类案件？
Java不会警告您，如果方法抛出未检查的异常，您将如何处理这种情况？在这里，你能做的最好的事情就是检查javadoc或调用方法的源，看看它是否抛出任何异常。或者只是为了捕捉代码中调用此方法的任何异常。
如果你问为什么Kotlin不像java那样没有检查过的异常，那么关于异常的官方Kotlin文档会解释他们为什么决定放弃检查过的例外。报价：
对小程序的检查得出的结论是，要求异常规范既可以提高开发人员的生产力，也可以提高代码质量，但大型软件项目的经验表明，结果不同——生产力降低，代码质量几乎没有或根本没有提高。
UPD:由kotlin-lang建筑师撰写的关于此事的文章：https://elizarov.medium.com/kotlin-and-exceptions-8062f589d07
Kotlin不会阻止捕获任何或所有异常；它只是没有像Java那样强制这样做。
所以你仍然可以做例如：
try {
ParcelFileDescriptor.open(file, ParcelFileDescriptor.MODE_READ_WRITE)
} catch (x: IOException) {
// …
}
至于您如何知道该方法可能引发IOException……这很棘手。如果它是一个Java方法，那么它的JavaDoc当然会指定它(您可以从IDE中看到(。但如果是Kotlin，那么文档可能会说；或者如果你有源代码，你可以检查一下。但恐怕没有真正的办法知道！您所能做的就是猜测——并确保在关键点捕获所有异常。
将所有例外情况视为未经检查并非没有争议；请参阅此长期讨论。
显然，在某些情况下，Java样式检查的异常是不切实际的：例如，在调用lambdas或函数引用时。(在这种情况下，Java本身会强制您处理或包装已检查的异常，这可能很难处理。(对于覆盖多层抽象的大程序来说，存在异常冒出的问题，以至于它们毫无意义；通常的解决方案是异常翻译：捕捉它们并重新考虑更合适的。还有一个问题是，太多糟糕的开发人员只是抓住所有异常并忽略它们(或者，充其量是记录它们(，而没有考虑应该如何或在哪里处理它们。
但你可能会认为，放弃所有异常检查就是把婴儿和洗澡水一起扔出去…
(我建议Kotlin应该进行异常推断——计算出一个方法可以抛出哪些未捕获的异常，并为它们假设@Throws声明——这将解决周围的大多数问题，因为知道哪些异常可以在任何时候抛出，而不需要捕获它们或使任何现有代码无效。但我可能没有看到这方面的一些问题，因为虽然这对我来说显然是个好主意，但它并没有得到很好的反响…(