如何测试捕获异常并重抛自定义RuntimeException的Android代码？

看起来你遇到的核心矛盾是：测试时异常的流转完全没按预期走——要么原始异常没被捕获包装，要么测试框架的异常预期判断出现了冲突。我们一步步来排查和解决：

1. 先确认测试代码的调用路径 #

首先要保证你的测试是直接调用包含那个try-catch逻辑的业务方法，而不是在测试代码里直接触发MalformedURLException。举个例子：
假设你的业务逻辑是这样的：

public class DownloadProcessor {
    private String downloadUrlString;

    public void validateDownloadUrl() {
        try {
            new URL(downloadUrlString);
        } catch (MalformedURLException e) {
            throw new CustomMalformedDataException(downloadUrlString, e);
        }
    }
}

那你的测试代码应该调用validateDownloadUrl()方法，而不是在测试里直接写new URL("invalid-url")——如果直接写后者，抛出的就是原始异常，根本没走到你的catch块里，自然会出现测试失败的情况。

2. 换用显式捕获的方式替代@Test(expected) #

有时候Android的Instrumentation测试对@Test(expected)的处理会有一些奇怪的行为，尤其是涉及RuntimeException包装检查的时候。改用显式的try-catch来验证异常，会更可靠：

@Test
public void testInvalidUrlThrowsCustomException() {
    DownloadProcessor processor = new DownloadProcessor();
    processor.setDownloadUrlString("http://[invalid-url"); // 构造一个肯定会触发MalformedURLException的字符串

    try {
        processor.validateDownloadUrl();
        // 如果走到这里，说明异常没被抛出，测试失败
        fail("Expected CustomMalformedDataException to be thrown");
    } catch (CustomMalformedDataException e) {
        // 验证异常的信息和根源是否符合预期
        assertTrue(e.getMessage().contains("http://[invalid-url"));
        assertTrue(e.getCause() instanceof MalformedURLException);
    }
}

这种方式不仅能验证异常类型，还能额外检查异常的细节（比如错误消息、原始异常），测试更健壮。

3. 排查自定义异常的构造逻辑 #

你的CustomMalformedDataException代码看起来是没问题的，但可以再确认一下：第二个构造函数确实把原始的MalformedURLException作为cause传递给了父类，这样getCause()能正确拿到原始异常，保证包装逻辑是完整的。

为什么之前的@Test(expected)会失败？ #

当你写@Test(expected = MalformedURLException.class)时，测试框架预期捕获的是这个原始异常，但你的代码已经把它包装成了CustomMalformedDataException，所以框架会认为抛出了非预期的异常；而当你写@Test(expected = CustomMalformedDataException.class)时，如果测试代码没有正确调用到你的业务方法（比如直接触发了原始异常），或者Instrumentation环境有特殊的异常拦截逻辑，就会导致框架捕获到原始异常，从而失败。

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