ContentResolver.takePersistableUriPermission未文档化异常的处理与排查

一、核心处理思路 #

虽然官方文档未标注该方法会抛出异常，但实际运行中确实存在触发运行时异常的可能。处理的核心原则是：先针对性覆盖已知风险异常，再兜底处理未知情况，既要避免程序崩溃，也要给用户明确的错误提示（比如“无法获取持久化权限，请重新选择文档”）。

二、方案A与方案B的有效性分析 #

• 方案A（捕获SecurityException）：这是最推荐的基础处理方式。该异常是此方法最常抛出的类型——比如获取到的URI临时权限已过期、或者URI并非通过ACTION_OPEN_DOCUMENT这类SAF（存储访问框架）操作获取的（只有SAF返回的URI才能申请持久化权限）。精准捕获这个异常，能覆盖绝大多数真实场景的失败情况，且不会误抓其他无关异常。
• 方案B（捕获Exception）：属于兜底性处理手段，能覆盖所有RuntimeException，但缺点是可能会将一些本应提前规避的错误（比如myUri为null导致的NullPointerException）一并捕获，不利于后续问题排查。如果你的代码已经完成前置校验（比如确保myUri非空、是合法的SAF URI），可以将它作为补充，但不建议单独使用。

除了这两种，还有更严谨的组合处理方式：

1. 先做前置校验：比如检查myUri是否以content://开头、是否通过SAF相关Intent返回；
2. 调用方法时捕获SecurityException；
3. 最后用catch (RuntimeException e)兜底处理其他未预料到的异常（比如传入无效flag导致的IllegalArgumentException）。

三、如何找出该方法所有可能抛出的RuntimeException #

1. 查看Android源码：直接翻阅ContentResolver.takePersistableUriPermission()的实现逻辑，它最终会调用系统服务的相关方法，能明确看到抛出异常的场景：
   • 临时权限未授予时，抛出SecurityException；
   • URI格式无效、对应文档不存在时，可能抛出IllegalArgumentException或SecurityException；
   • 传入的flag不是FLAG_GRANT_READ_URI_PERMISSION或FLAG_GRANT_WRITE_URI_PERMISSION时，抛出IllegalArgumentException。
2. 手动测试边界场景：自行构造各类异常情况验证：
   • 传入null的URI；
   • 传入本地文件的file:// URI（非SAF的content URI）；
   • 传入已被删除的文档URI；
   • 传入自行构造的非合法content URI；
   • 传入错误的flag值（比如0）。
3. 参考社区真实案例：开发者在技术论坛分享的踩坑经历，能补充官方文档未提及的异常场景。

内容的提问来源于stack exchange，提问作者user17856705