2008-10-01 06:56:08 8 Comments

How can I use JUnit4 idiomatically to test that some code throws an exception?

While I can certainly do something like this:

public void testFooThrowsIndexOutOfBoundsException() {
  boolean thrown = false;

  try {
  } catch (IndexOutOfBoundsException e) {
    thrown = true;


I recall that there is an annotation or an or something that is far less kludgy and far more in-the-spirit of JUnit for these sorts of situations.


@MariuszS 2013-11-15 19:17:15

BDD Style Solution: JUnit 4 + Catch Exception + AssertJ

import static com.googlecode.catchexception.apis.BDDCatchException.*;

public void testFooThrowsIndexOutOfBoundsException() {

    when(() -> foo.doStuff());





@skaffman 2008-10-01 07:12:13

JUnit 4 has support for this:

@Test(expected = IndexOutOfBoundsException.class)
public void testIndexOutOfBoundsException() {

    ArrayList emptyList = new ArrayList();
    Object o = emptyList.get(0);


Reference :

@Oh Chin Boon 2011-06-27 14:50:57

This piece of code will not work if you expect an exception only somewhere in your code, and not a blanket like this one.

@Artem Oboturov 2012-04-27 16:01:48

@skaffman This wouldn't work with org.junit.experimental.theories.Theory runned by org.junit.experimental.theories.Theories

@Rachel 2012-06-08 18:48:51

@skaffman: Is there a way to do similar thing in junit 3.8, expect method to throw exception?

@bacar 2012-07-06 10:32:36

I don't use that annotation and don't have that problem...

@Kevin Wittek 2015-01-22 14:36:08

Roy Osherove discourages this kind of Exception testing in The art of Unit Testing, since the Exception might be anywhere inside the test and not only inside the unit under test.

@sara 2016-03-22 15:06:47

agree with @Kiview's point, this way might not actually test what you wanted to test. false positives are a pain.

@nickbdyer 2016-05-03 12:22:13

I disagree with @Kiview/Roy Osherove. In my view, tests should be for behaviour, not implementation. By testing that a specific method can throw an error, you are tying your tests directly to the implementation. I would argue that testing in the method shown above provides a more valuable test. The caveat I would add is that in this case I would test for a custom exception, so that I know I am getting the exception I really want.

@Kevin Wittek 2016-05-03 16:17:36

@nickbdyer Of course you want to test the behaviour. But do you want to test the behaviour of ArrayList? constructor or of the get() method? In the example above, you are testing both. The test would pass if your constructor would throw this exception, although you want to test the get() method.

@nickbdyer 2016-05-03 16:33:09

Neither. I want to test the behaviour of the class. What is important, is that if I try to retrieve something that isn't there, I get an exception. The fact that the data structure is ArrayList that responds to get() is irrelevant. If I chose in the future to move to a primitive array, I would then have to change this test implementation. The data structure should be hidden, so that the test can focus on the behaviour of the class.

@Halley 2016-11-08 12:28:59

This question pops up in Google when you search for JUnit Exceptions. Can someone edit this answer and provide the info related to JUnit 4.7's features?

@Dylanthepiguy 2017-03-16 21:47:14

@OhChinBoon You could make your own subclass of Exception or RuntimeException and catch that. And then make sure your subclass isn't being used in more than one place

@NoName 2017-10-16 13:01:59

public void testIndexOutOfBoundsException() throws IndexOutOfBoundsException { ... } should be added.

@gstackoverflow 2018-02-01 16:51:31

Could you please take a look, please…

@Juan Salvador 2018-02-09 19:10:27

This works nice !.... but, it seems that when you use this sort of solutions, actually you are not doing the right thing with exceptions. Please read the link the new solution3. Errors and Exceptions should not interrupt the unit testing.

@benez 2018-02-14 10:45:49

i think this way is legit as well, just a personal preference. but it is also nice to mention that this might "catch" all exceptions of that type within your test and sometimes it will be more accurate to catch the exception inside the test around a specific method call, where you expect the exception to occur. so if you keep that in mind, it's legit to write a test just like this

@Vivek Chavda 2018-06-20 17:50:40

@nickbdyer I think there's some miscommunication here. Kiview/Kevin Wittek is saying any method used in the test could throw the exception and cause the test to pass without reaching the statement that is actually supposed to throw an exception of that type. The data structure being used is irrelevant to his point. If the structure is wrapped inside a method of the class under test, you're right that it doesn't matter which statement inside that class is throwing the exception, but he wasn't contradicting that.

@walsh 2015-08-05 08:05:50

in junit, there are four ways to test exception.


  • for junit5.x, you can use assertThrows as following

    public void testFooThrowsIndexOutOfBoundsException() {
        Throwable exception = assertThrows(IndexOutOfBoundsException.class, () -> foo.doStuff());
        assertEquals("expected messages", exception.getMessage());


  • for junit4.x, use the optional 'expected' attribute of Test annonation

    @Test(expected = IndexOutOfBoundsException.class)
    public void testFooThrowsIndexOutOfBoundsException() {
  • for junit4.x, use the ExpectedException rule

    public class XxxTest {
        public ExpectedException thrown = ExpectedException.none();
        public void testFooThrowsIndexOutOfBoundsException() {
            //you can test the exception message like
            thrown.expectMessage("expected messages");
  • you also can use the classic try/catch way widely used under junit 3 framework

    public void testFooThrowsIndexOutOfBoundsException() {
        try {
            fail("expected exception was not occured.");
        } catch(IndexOutOfBoundsException e) {
            //if execution reaches here, 
            //it indicates this exception was occured.
            //so we need not handle it.
  • so

    • if you like junit 5, then you should like the 1st one
    • the 2nd way is used when you only want test the type of exception
    • the first and last two are used when you want test exception message further
    • if you use junit 3, then the 4th one is preferred
  • for more info, you can read this document and junit5 user guide for details.

@Nicolas Cornette 2016-06-16 08:57:18

For me this is the best answer, it covers all the ways very clearly, thanks ! Personally I continue using the 3rd option even with Junit4 for readability, to avoid empty catch block you can also catch Throwable and assert type of e

@miuser 2017-03-02 09:23:52

Is it possible to use ExpectedException to expect checked exception?

@Paul Samsotha 2018-05-05 01:27:48

All it is is an accumulation of the top three answers. IMO, this answer shouldn't even have been posted if it is not adding nothing new. Just answering (a popular question) for the rep. Pretty useless.

@walsh 2018-06-08 13:47:20

sure, because you can pass any type derived from Trowable to the method ExpectedException.expect. please see it's signature. @miuser

@MangduYogii 2019-04-16 12:54:07

    public void  testFooThrowsIndexOutOfBoundsException() throws Exception {
         try {
            } catch (IndexOutOfBoundsException e) {
                       assertEquals(IndexOutOfBoundsException .class, ex.getCause().getClass());
                      throw e;



Here is another way to check method thrown correct exception or not.

@Brice 2016-12-07 14:19:24


  • pre-JDK8 : I will recommend the old good try-catch block. (Don't forget to add a fail() assertion before the catch block)

  • post-JDK8 : Use AssertJ or custom lambdas to assert exceptional behaviour.

Regardless of Junit 4 or JUnit 5.

the long story

It is possible to write yourself a do it yourself try-catch block or use the JUnit tools (@Test(expected = ...) or the @Rule ExpectedException JUnit rule feature).

But these way are not so elegant and don't mix well readability wise with other tools. Moreover JUnit tooling do have some pitfalls.

  1. The try-catch block you have to write the block around the tested behavior, and write the assertion in the catch block, that may be fine but many find taht this style interrupts the reading flow of a test. Also you need to write an at the end of the try block otherwise the test may miss one side of the assertions ; PMD, findbugs or Sonar will spot such issues.

  2. The @Test(expected = ...) feature is interesting as you can write less code and then writing this test is supposedly less prone to coding errors. But ths approach is lacking a some areas.

    • If the test needs to check additional things on the exception like the cause or the message (good exception messages are really important, having a precise exception type may not be enough).
    • Also as the expectation is placed around in the method, depending on how the tested code is written then the wrong part of the test code can throw the exception, leading to false positive test and I m not sure that PMD, findbugs or Sonar will give hints on such code.

      @Test(expected = WantedException.class)
      public void call2_should_throw_a_WantedException__not_call1() {
          // init tested
          tested.call1(); // may throw a WantedException
          // call to be actually tested
          tested.call2(); // the call that is supposed to raise an exception
  3. The ExpectedException rule is also an attempt to fix the previous caveats, but it feels a bit awkward to use as it uses an expectation style, EasyMock users knows very well this style. It might be convenient for some, but if you follow Behaviour Driven Development (BDD) or Arrange Act Assert (AAA) principles the ExpectedException rule won't fit in those writing style. Aside of that it may suffer from the same issue as the as the @Test way, depending where you place the expectation.

    @Rule ExpectedException thrown = ExpectedException.none()
    public void call2_should_throw_a_WantedException__not_call1() {
        // expectations
        // init tested
        tested.call1(); // may throw a WantedException
        // call to be actually tested
        tested.call2(); // the call that is supposed to raise an exception

    Even the expected exception is placed before the test statement, it breaks your reading flow if the tests follow BDD or AAA.

    Also see this comment issue on JUnit of the author of ExpectedException. JUnit 4.13-beta-2 even deprecates this mechanism:

    Pull request #1519: Deprecate ExpectedException

    The method Assert.assertThrows provides a nicer way for verifying exceptions. In addition the use of ExpectedException is error-prone when used with other rules like TestWatcher because the order of rules is important in that case.

So these above options have all their load of caveats, and clearly not immune to coder errors.

  1. There's a project I became aware after creating this answer that looks promising, it's catch-exception.

    As the description of the project says, it let a coder write in a fluent line of code catching the exception and offer this exception for later assertion. And you can use any assertion library like Hamcrest or AssertJ.

    A rapid example taken from the home page :

    // given: an empty list
    List myList = new ArrayList();
    // when: we try to get the first element of the list
    // then: we expect an IndexOutOfBoundsException
            .hasMessage("Index: 1, Size: 0") 

    As you can see the code is really straightforward, you catch the exception on a specific line, the then API is an alias that will use AssertJ APIs (similar to using assertThat(ex).hasNoCause()...). At some point the project relied on FEST-Assert the ancestor of AssertJ. EDIT: It seems the project is brewing a Java 8 Lambdas support.

    Currently this library has two shortcomings :

    • At the time of this writing it is noteworthy to say this library is based on Mockito 1.x as it creates a mock of the tested object behind the scene. As Mockito is still not updated this library cannot work with final classes or final methods. And even if it was based on mockito 2 in the current version, this would require to declare a global mock maker (inline-mock-maker), something that may not what you want, as this mockmaker has different drawbacks that the regular mockmaker.

    • It requires yet another test dependency.

    These issues won't apply once the library will support lambdas, however the functionality will be duplicated by AssertJ toolset.

    Taking all into account if you don't want to use the catch-exception tool, I will recommend the old good way of the try-catch block, at least up to the JDK7. And for JDK 8 users you might prefer to use AssertJ as it offers may more than just asserting exceptions.

  2. With the JDK8, lambdas enter the test scene, and they have proved to be an interesting way to assert exceptional behaviour. AssertJ has been updated to provide a nice fluent API to assert exceptional behaviour.

    And a sample test with AssertJ :

    public void test_exception_approach_1() {
                .isThrownBy(() -> someBadIOOperation())
    public void test_exception_approach_2() {
        assertThatThrownBy(() -> someBadIOOperation())
    public void test_exception_approach_3() {
        // when
        Throwable thrown = catchThrowable(() -> someBadIOOperation());
        // then
  3. With a near complete rewrite of JUnit 5, assertions have been improved a bit, they may prove interesting as an out of the box way to assert properly exception. But really the assertion API is still a bit poor, there's nothing outside assertThrows.

    @DisplayName("throws EmptyStackException when peeked")
    void throwsExceptionWhenPeeked() {
        Throwable t = assertThrows(EmptyStackException.class, () -> stack.peek());
        Assertions.assertEquals("...", t.getMessage());

    As you noticed assertEquals is still returning void, and as such doesn't allow chaining assertions like AssertJ.

    Also if you remember name clash with Matcher or Assert, be prepared to meet the same clash with Assertions.

I'd like to conclude that today (2017-03-03) AssertJ's ease of use, discoverable API, rapid pace of development and as a de facto test dependency is the best solution with JDK8 regardless of the test framework (JUnit or not), prior JDKs should instead rely on try-catch blocks even if they feel clunky.

This answer has been copied from another question that don't have the same visibility, I am the same author.

@anre 2017-08-03 12:13:39

Adding org.junit.jupiter:junit-jupiter-engine:5.0.0-RC2 dependency (in addition to the already existing junit:junit:4.12) to be able to use assertThrows is perhaps not the preferred solution, but did not cause any issues for me.

@Pim Hazebroek 2018-07-06 06:34:44

I'm a fan of using the ExpectedException rule but it always bothered me that it breaks with AAA. You've wrote an excellent article to describe all the different approaches and you've definitely encouraged me to try AssertJ :-) Thanks!

@Brice 2018-07-06 07:54:41

@PimHazebroek thanks. AssertJ API is quite rich. Better in my opinion that what JUnit proposes out of the box.

@Dherik 2018-01-25 11:10:01

The most flexible and elegant answer for Junit 4 I found in the Mkyong blog. It has the flexibility of the try/catch using the @Rule annotation. I like this approach because you can read specific attributes of a customized exception.

package com.mkyong;

import com.mkyong.examples.CustomerService;
import com.mkyong.examples.exception.NameNotFoundException;
import org.junit.Rule;
import org.junit.Test;
import org.junit.rules.ExpectedException;

import static org.hamcrest.CoreMatchers.containsString;
import static;
import static org.hamcrest.Matchers.hasProperty;

public class Exception3Test {

    public ExpectedException thrown = ExpectedException.none();

    public void testNameNotFoundException() throws NameNotFoundException {

        //test specific type of exception

        //test message
        thrown.expectMessage(is("Name is empty!"));

        //test detail
        thrown.expect(hasProperty("errCode"));  //make sure getters n setters are defined.
        thrown.expect(hasProperty("errCode", is(666)));

        CustomerService cust = new CustomerService();



@Houssem Badri 2018-08-08 10:43:49

try {
    my method();
    fail( "This method must thrwo" );
} catch (Exception ex) {

@hellow 2018-08-08 11:24:01

You are answering on a 10 year old question, please expand your answer, why you think it provides something new, that the accepted answer does not cover. Also always try to tell something about your code and provide documentation or explanation.

@Hulk 2018-08-08 12:07:56

This is basically a duplicate of this 10 year old answer (except for the check for the error message).

@Houssem Badri 2018-08-08 16:23:35

I don't know why to downvote. There is no duplication. Please have a look at the check of the error msg. This is the right answer that I used today with my team @hellow

@hellow 2018-08-08 19:47:36

It's not always the same person who complains about your question/answer and downvots you (like in this case, I didn't, but please take my words and expand your answer).

@Nithin 2018-08-09 09:15:44

I am not sure if the test depending just on the error message is a good practice.

@Houssem Badri 2018-08-09 10:00:41

Yeah it is a good practice and useful when you have many error messages, so that you make sure that this specific one will be thrown (many possible exceptions)

@Houssem Badri 2018-08-09 10:01:57

Please what do you mean by expand answer Hebrow, this answer is for the question, so if you understand well the question and the code on it so the answer will be straightforward, he is needing just some code

@Piotr R 2018-07-18 11:32:37

I recomend library assertj-core to handle exception in junit test

In java 8, like this:


Throwable throwable = catchThrowable(() -> anyService.anyMethod(object));

AnyException anyException = (AnyException) throwable;

@Donatello 2018-04-06 15:52:07

Junit4 solution with Java8 is to use this function:

public Throwable assertThrows(Class<? extends Throwable> expectedException, java.util.concurrent.Callable<?> funky) {
    try {;
    } catch (Throwable e) {
        if (expectedException.isInstance(e)) {
            return e;
        throw new AssertionError(
                String.format("Expected [%s] to be thrown, but was [%s]", expectedException, e));
    throw new AssertionError(
            String.format("Expected [%s] to be thrown, but nothing was thrown.", expectedException));

Usage is then:

            () -> finalObject.checkSomething(null));

Note that the only limitation is to use a final object reference in lambda expression. This solution allows to continue test assertions instead of expecting thowable at method level using @Test(expected = IndexOutOfBoundsException.class) solution.

@Mike Nakis 2015-12-18 18:52:21

Java 8 solution

If you would like a solution which:

  • Utilizes Java 8 lambdas
  • Does not depend on any JUnit magic
  • Allows you to check for multiple exceptions within a single test method
  • Checks for an exception being thrown by a specific set of lines within your test method instead of any unknown line in the entire test method
  • Yields the actual exception object that was thrown so that you can further examine it

Here is a utility function that I wrote:

public final <T extends Throwable> T expectException( Class<T> exceptionClass, Runnable runnable )
    catch( Throwable throwable )
        if( throwable instanceof AssertionError && throwable.getCause() != null )
            throwable = throwable.getCause(); //allows "assert x != null : new IllegalArgumentException();"
        assert exceptionClass.isInstance( throwable ) : throwable; //exception of the wrong kind was thrown.
        assert throwable.getClass() == exceptionClass : throwable; //exception thrown was a subclass, but not the exact class, expected.
        @SuppressWarnings( "unchecked" )
        T result = (T)throwable;
        return result;
    assert false; //expected exception was not thrown.
    return null; //to keep the compiler happy.

(taken from my blog)

Use it as follows:

public void testThrows()
    RuntimeException e = expectException( RuntimeException.class, () -> 
            throw new RuntimeException( "fail!" );
        } );
    assert e.getMessage().equals( "fail!" );

@Dilini Rajapaksha 2017-01-10 01:29:43

Update: JUnit5 has an improvement for exceptions testing: assertThrows.

following example is from: Junit 5 User Guide

void exceptionTesting() {
    Throwable exception = assertThrows(IllegalArgumentException.class, () -> 
        throw new IllegalArgumentException("a message");
    assertEquals("a message", exception.getMessage());

Original answer using JUnit 4.

There are several ways to test that an exception is thrown. I have also discussed the below options in my post How to write great unit tests with JUnit

Set the expected parameter @Test(expected = FileNotFoundException.class).

@Test(expected = FileNotFoundException.class) 
public void testReadFile() { 

Using try catch

public void testReadFile() { 
    try {
        fail("Expected a FileNotFoundException to be thrown");
    } catch (FileNotFoundException e) {
        assertThat(e.getMessage(), is("The file test.txt does not exist!"));


Testing with ExpectedException Rule.

public ExpectedException thrown = ExpectedException.none();

public void testReadFile() throws FileNotFoundException {

    thrown.expectMessage(startsWith("The file test.txt"));

You could read more about exceptions testing in JUnit4 wiki for Exception testing and bad.robot - Expecting Exceptions JUnit Rule.

@Shessuky 2015-03-09 11:21:37

We can use an assertion fail after the method that must return an exception:

   methodThatThrowMyException();"MyException is not thrown !");
} catch (final Exception exception) {
   // Verify if the thrown exception is instance of MyException, otherwise throws an assert failure
   assertTrue(exception instanceof MyException, "An exception other than MyException is thrown !");
   // In case of verifying the error message
   MyException myException = (MyException) exception;
   assertEquals("EXPECTED ERROR MESSAGE", myException.getMessage());

@NamshubWriter 2015-08-30 01:06:51

The second catch would swallow the stack trace if some other exception is thrown, losing useful information

@Mohit ladia 2017-11-09 06:23:17

There are two ways of writing test case

  1. Annotate the test with the exception which is thrown by the method. Something like this @Test(expected = IndexOutOfBoundsException.class)
  2. You can simply catch the exception in the test class using the try catch block and assert on the message that is thrown from the method in test class.

    catch(exception to be thrown from method e)
         assertEquals("message", e.getmessage());

I hope this answers your query Happy learning...

@heio 2017-10-04 11:06:42

My solution using Java 8 lambdas:

public static <T extends Throwable> T assertThrows(Class<T> expected, ThrowingRunnable action) throws Throwable {
    try {;"Did not throw expected " + expected.getSimpleName());
        return null; // never actually
    } catch (Throwable actual) {
        if (!expected.isAssignableFrom(actual.getClass())) { // runtime '!(actual instanceof expected)'
            System.err.println("Threw " + actual.getClass().getSimpleName() 
                               + ", which is not a subtype of expected " 
                               + expected.getSimpleName());
            throw actual; // throw the unexpected Throwable for maximum transparency
        } else {
            return (T) actual; // return the expected Throwable for further examination

You have to define a FunctionalInterface, because Runnable doesn't declare the required throws.

public interface ThrowingRunnable {
    void run() throws Throwable;

The method can be used as follows:

class CustomException extends Exception {
    public final String message;
    public CustomException(final String message) { this.message = message;}
CustomException e = assertThrows(CustomException.class, () -> {
    throw new CustomException("Lorem Ipsum");
assertEquals("Lorem Ipsum", e.message);

@NamshubWriter 2017-10-01 16:42:29

Now that JUnit 5 has released, the best option is to use Assertions.assertThrows() (see the Junit 5 User Guide).

Here is an example that verifies an exception is thrown, and uses Truth to make assertions on the exception message:

public class FooTest {
  public void doStuffThrowsIndexOutOfBoundsException() {
    Foo foo = new Foo();

    IndexOutOfBoundsException e = assertThrows(
        IndexOutOfBoundsException.class, foo::doStuff);


The advantages over the approaches in the other answers are:

  1. Built into JUnit
  2. You get a useful exception message if the code in the lambda doesn't throw an exception, and a stacktrace if it throws a different exception
  3. Concise
  4. Allows your tests to follow Arrange-Act-Assert
  5. You can precisely indicate what code you are expecting to throw the exception
  6. You don't need to list the expected exception in the throws clause
  7. You can use the assertion framework of your choice to make assertions about the caught exception

A similar method will be added to org.junit Assert in JUnit 4.13.

@Clockwork 2019-03-08 15:19:24

This approach is clean, but I don't see how this allows our test to follow "Arrange-Act-Assert", since we have to wrap the "Act" part in an "assertThrow", which is an assert.

@NamshubWriter 2019-03-11 17:10:43

@Clockwork The lambda is the "act". The goal of Arrange-Act-Assert is to make the code clean and simple (and therefore easy to understand and maintain). As you stated, this approach is clean.

@Clockwork 2019-03-11 18:02:00

I was still hoping I could assert the throw and the exception on the end of the test though, in the "assert" part. In this approach, you need to wrap the act in a first assert to catch it first.

@NamshubWriter 2019-03-11 18:36:32

That would require more code in every test to do the assertion. That's more code and would be error-prone.

@NamshubWriter 2010-05-29 17:16:23

Edit Now that JUnit5 has released, the best option would be to use Assertions.assertThrows() (see my other answer).

If you haven't migrated to JUnit 5, but can use JUnit 4.7, you can use the ExpectedException Rule:

public class FooTest {
  public final ExpectedException exception = ExpectedException.none();

  public void doStuffThrowsIndexOutOfBoundsException() {
    Foo foo = new Foo();


This is much better than @Test(expected=IndexOutOfBoundsException.class) because the test will fail if IndexOutOfBoundsException is thrown before foo.doStuff()

See this article for details

@bacar 2012-07-06 11:41:55

@skaffman - If I've understood this correctly, it looks like the exception.expect is being applied only within one test, not the whole class.

@Mohammad Jafar Mashhadi 2013-06-29 08:05:57

If the exception we expect to be thrown is an checked exception, should we add throws or try-catch or test this situation in another way?

@TmTron 2013-09-27 14:35:58

IMHO the answer from rwoo below is a much better solution ( i.e. in this example when you throw new NullPointerException(); after foo.doStuff() the test will not fail with an NPE.

@Jason Thompson 2014-01-17 15:59:01

@MartinTrummer No code should run after foo.doStuff() since the exception is thrown and the method is exited. Having code after an expected exception (with the exception of closing resources in a finally) is unhelpful anyway since it should never be executed if the exception is thrown.

@TmTron 2014-01-20 09:32:41

@Jason Thompson: "should" is nice, but not bullet-proof: With verify-exception you can be sure that the test is okay, even if someone else added some code after doStuff(): when the new code passes, so does the test and more importantly: when the new code throws, the test will fail. the given "solution" would hide this fact (and moreover verify-exception is more concise and thus less error-prone):

@Jason Thompson 2014-01-20 14:51:23

@MartinTrummer What I'm struggling to understand is how code can execute after an exception is thrown. Perhaps you can give an example. My understanding is that as soon as an exception is thrown, the method exits with an exception. So if I had a function that looked like this: void myMethod { throw new IllegalStateException(); executeOtherMethod(); } As far as I know, there is no way executeOtherMethod() would ever be called. So it's a non issue. This code doesn't change how java works, but rather tells the test runner that the method will throw an exception and some characteristics of it.

@TmTron 2014-01-21 06:14:23

@Jason but that's not the code you have. you have foo.doStuff(); bar.doStuff(); - and you expect foo.doStuff(); to throw. so if it does throw, bar.doStuff() is never executed (that's bad). but even worse is the case, when the code changes and foo.doStuff() does not throw anymore. now it's possible that bar.doStuff() throws insteead- the test passes - and you don't notice that the new code actually broke the original expectations that foo.doStuff(); throws.

@Tom 2014-06-20 19:41:47

@JasonThompson: usually in a testing environment the exception is swallowed and you assert it was thrown. The test doesn't exit in that case.

@Tom 2014-06-20 19:42:33

As I commented on rwoo's answer, I think the drawback with his library is that you can't proxy every object [for example classes that are final?]... but I'm not sure without trying it out.

@Dawood says reinstate Monica 2014-07-26 10:58:47

This is the best approach. There are two advantages here, compared to skaffman's solution. Firstly, the ExpectedException class has ways of matching the exception's message, or even writing your own matcher that depends on the class of exception. Secondly, you can set your expectation immediately before the line of code that you expect to throw the exception - which means your test will fail if the wrong line of code throws the exception; whereas there's no way to do that with skaffman's solution.

@singe3 2014-08-07 08:17:42

Doesn't work when we extend TestCase, the test fails although the exception is thrown as expected

@NamshubWriter 2014-09-21 16:56:06

@singe31 The OP asked about JUnit4, and JUnit4-style tests shouldn't extend TestCase

@mkobit 2014-11-12 23:31:46

@DavidWallace the problem I with this approach is if you want to assert or check any behavior after the executed methods (like verify that any mock behavior did or did not occur) you cannot do it because your test will exit execution when the exception is throw. This can lead to unexpected test behavior if you have some verify after the method call that you believe is getting executed, but it actually isn't.

@Dawood says reinstate Monica 2014-11-12 23:36:17

@MikeKobit - So are you testing that the exception is thrown, or are you testing something else? I am a strong advocate of the "one test case, one assertion" approach - that is, if you're testing the throwing of the exception, there shouldn't be any other asserts or verifies occurring after the exception.

@mkobit 2014-11-13 01:14:08

@DavidWallace I've had the case before where I want to test a method on a component that will throw an exception. I also want to make sure that a side effect has/has not happened. If I am using a mock framework like Mockito with the answer above, I wouldn't be able to verify any behavior. Example demoing sort of what I am talking about -…

@Dawood says reinstate Monica 2014-11-13 01:52:27

@MikeKobit OK, fair enough, that sounds reasonable. I imagine that would be a fairly rare kind of test case though.

@Thomas 2015-04-01 01:07:13

It looks like Eclipse's coverage tool has trouble with this (not that that really matters)

@NamshubWriter 2015-05-10 14:38:51

@MJafarMash if the exception you expect to throw is checked, then you would add that exception to the throws clause of the test method. You do the same any time you are testing a method that is declared to throw a checked exception, even if the exception isn't triggered in the particular test case.

@Ungeheuer 2016-10-27 18:29:18

@DavidWallace how does ExpectedException test for exception message? I dont see anything in the 4.12 API for that.

@Dawood says reinstate Monica 2016-10-27 18:31:58

You can pass a Hamcrest Matcher to expect to analyse the exception. Or even easier - you can pass a String to expectMessage that you expect to be a substring of the message.…

@Marc Bouvier 2018-04-26 08:52:34

You can do it that way : exception.expectMessage("foo bar");

@fahrenx 2017-10-01 12:03:38

With Java 8 you can create a method taking a code to check and expected exception as parameters:

private void expectException(Runnable r, Class<?> clazz) { 
    try {;
      fail("Expected: " + clazz.getSimpleName() + " but not thrown");
    } catch (Exception e) {
      if (!clazz.isInstance(e)) fail("Expected: " + clazz.getSimpleName() + " but " + e.getClass().getSimpleName() + " found", e);

and then inside your test:

expectException(() -> list.sublist(0, 2).get(2), IndexOutOfBoundsException.class);


  • not relying on any library
  • localised check - more precise and allows to have multiple assertions like this within one test if needed
  • easy to use

@Alex Collins 2015-03-10 21:49:47

IMHO, the best way to check for exceptions in JUnit is the try/catch/fail/assert pattern:

// this try block should be as small as possible,
// as you want to make sure you only catch exceptions from your code
try {
    fail(); // fail if this does not throw any exception
} catch(MyException e) { // only catch the exception you expect,
                         // otherwise you may catch an exception for a dependency unexpectedly
    // a strong assertion on the message, 
    // in case the exception comes from anywhere an unexpected line of code,
    // especially important if your checking IllegalArgumentExceptions
    assertEquals("the message I get", e.getMessage()); 

The assertTrue might be a bit strong for some people, so assertThat(e.getMessage(), containsString("the message"); might be preferable.

@Jobin Joseph 2016-12-08 05:48:19

In JUnit 4 or later you can test the exceptions as follows

public ExpectedException exceptions = ExpectedException.none();

this provides a lot of features which can be used to improve our JUnit tests.
If you see the below example I am testing 3 things on the exception.

  1. The Type of exception thrown
  2. The exception Message
  3. The cause of the exception

public class MyTest {

    public ExpectedException exceptions = ExpectedException.none();

    ClassUnderTest classUnderTest;

    public void setUp() throws Exception {
        classUnderTest = new ClassUnderTest();

    public void testAppleisSweetAndRed() throws Exception {

        exceptions.expectMessage("this is the exception message");

        classUnderTest.methodUnderTest("param1", "param2");


@Rafal Borowiec 2014-07-07 22:35:19

As answered before, there are many ways of dealing with exceptions in JUnit. But with Java 8 there is another one: using Lambda Expressions. With Lambda Expressions we can achieve a syntax like this:

public void verifiesTypeAndMessage() {
    assertThrown(new DummyService()::someMethod)
            .hasMessage("Runtime exception occurred")

assertThrown accepts a functional interface, whose instances can be created with lambda expressions, method references, or constructor references. assertThrown accepting that interface will expect and be ready to handle an exception.

This is relatively simple yet powerful technique.

Have a look at this blog post describing this technique:

The source code can be found here:

Disclosure: I am the author of the blog and the project.

@Selwyn 2015-03-31 02:07:52

I like this solution but can I download this from a maven repo?

@NamshubWriter 2015-05-10 14:35:20

@Airduster one implementation of this idea that's available on Maven is

@Cristiano Fontes 2015-06-01 12:25:20

They should submit this as a pull request to JUnit...

@NamshubWriter 2015-07-21 02:18:27

@CristianoFontes a simpler version of this API is slated for JUnit 4.13. See…

@Andy 2017-04-28 19:48:45

@RafalBorowiec technically, new DummyService()::someMethod is a MethodHandle, but this approach works equally well with lambda expressions.

@Vadzim 2017-12-19 11:02:02

@NamshubWriter, it seems that junit 4.13 was abandoned in favor of junit 5:…

@NamshubWriter 2017-12-19 15:45:19

@Vadzim JUnit 4.13 is not abandoned. The team realizes that some people cannot migrate to JUnit 5 and 4.13 has some nice fixes, but most of the recent efforts have been focused on the 5.x code base.

@Shirsh Sinha 2016-10-29 07:34:18

Take for example, you want to write Junit for below mentioned code fragment

public int divideByZeroDemo(int a,int b){

    return a/b;

public void exceptionWithMessage(String [] arr){

    throw new ArrayIndexOutOfBoundsException("Array is out of bound");

The above code is to test for some unknown exception that may occur and the below one is to assert some exception with custom message.

public ExpectedException exception=ExpectedException.none();

private Demo demo;
public void setup(){

    demo=new Demo();
public void testIfItThrowsAnyException() {

    demo.divideByZeroDemo(5, 0);


public void testExceptionWithMessage(){

    exception.expectMessage("Array is out of bound");
    demo.exceptionWithMessage(new String[]{"This","is","a","demo"});

@weston 2016-03-05 11:07:24

Using an AssertJ assertion, which can be used alongside JUnit:

import static org.assertj.core.api.Assertions.*;

public void testFooThrowsIndexOutOfBoundsException() {
  Foo foo = new Foo();

  assertThatThrownBy(() -> foo.doStuff())

It's better than @Test(expected=IndexOutOfBoundsException.class) because it guarantees the expected line in the test threw the exception and lets you check more details about the exception, such as message, easier:

assertThatThrownBy(() ->
         throw new Exception("boom!");

Maven/Gradle instructions here.

@ycomp 2016-03-21 20:03:28

most concise way and nobody appreciates it, strange.. I only have one problem with the assertJ library, assertThat conflicts name-wise with junit's. more about assertJ throwby: JUnit: Testing Exceptions with Java 8 and AssertJ 3.0.0 ~

@weston 2016-03-24 08:46:58

@ycomp Well it is a new answer on a very old question, so the score difference is deceptive.

@Pierre Henry 2016-03-25 15:01:59

That's probably the best solution if one can use Java 8 and AssertJ !

@mike rodent 2016-10-11 16:13:43

@ycomp I suspect this name conflict may be by design: the AssertJ library therefore strongly encourages you never to use the JUnit assertThat, always the AssertJ one. Also the JUnit method returns only a "regular" type, whereas the AssertJ method returns an AbstractAssert subclass ... allowing stringing of methods as above (or whatever the technical terms is for this...).

@mike rodent 2016-10-11 16:14:47

@weston actually I've just used your technique in AssertJ 2.0.0. No excuse for not upgrading, no doubt, but though you might like to know.

@weston 2016-10-11 18:20:07

@mikerodent "allowing stringing of methods as above (or whatever the technical terms is for this...)" fluent would be the term. So, "... allowing fluent statements."

@weston 2016-10-11 18:21:02

@mikerodent that is interesting that it works in 2, I don't know why I thought was 3

@Daniel Käfer 2016-07-24 15:00:31

JUnit 5 Solution

void testFooThrowsIndexOutOfBoundsException() {    
  Throwable exception = expectThrows( IndexOutOfBoundsException.class, foo::doStuff );

  assertEquals( "some message", exception.getMessage() );

More Infos about JUnit 5 on

@Matt Welke 2016-03-10 05:10:05

I wanted to comment with my solution to this problem, which avoided needing any of the exception related JUnit code.

I used assertTrue(boolean) combined with try/catch to look for my expected exception to be thrown. Here's an example:

public void testConstructor() {
    boolean expectedExceptionThrown;
    try {
        // Call constructor with bad arguments
        double a = 1;
        double b = 2;
        double c = a + b; // In my example, this is an invalid option for c
        new Triangle(a, b, c);
        expectedExceptionThrown = false; // because it successfully constructed the object
    catch(IllegalArgumentException e) {
        expectedExceptionThrown = true; // because I'm in this catch block
    catch(Exception e) {
        expectedExceptionThrown = false; // because it threw an exception but not the one expected

@NamshubWriter 2016-07-05 02:21:27

The second catch would swallow the stack trace if some other exception is thrown, losing useful information

@Tor P 2013-06-05 20:12:23

Just make a Matcher that can be turned off and on, like this:

public class ExceptionMatcher extends BaseMatcher<Throwable> {
    private boolean active = true;
    private Class<? extends Throwable> throwable;

    public ExceptionMatcher(Class<? extends Throwable> throwable) {
        this.throwable = throwable;

    public void on() { = true;

    public void off() { = false;

    public boolean matches(Object object) {
        return active && throwable.isAssignableFrom(object.getClass());

    public void describeTo(Description description) {
        description.appendText("not the covered exception type");

To use it:

add public ExpectedException exception = ExpectedException.none();, then:

ExceptionMatcher exMatch = new ExceptionMatcher(MyException.class);

@Bruce Wayne 2015-05-22 19:09:24

Additionally to what NamShubWriter has said, make sure that:

  • The ExpectedException instance is public (Related Question)
  • The ExpectedException isn't instantiated in say, the @Before method. This post clearly explains all the intricacies of JUnit's order of execution.

Do not do this:

public ExpectedException expectedException;

public void setup()
    expectedException = ExpectedException.none();

Finally, this blog post clearly illustrates how to assert that a certain exception is thrown.

@Johan 2008-10-01 07:03:01

How about this: Catch a very general exception, make sure it makes it out of the catch block, then assert that the class of the exception is what you expect it to be. This assert will fail if a) the exception is of the wrong type (eg. if you got a Null Pointer instead) and b) the exception wasn't ever thrown.

public void testFooThrowsIndexOutOfBoundsException() {
  Throwable e = null;

  try {
  } catch (Throwable ex) {
    e = ex;

  assertTrue(e instanceof IndexOutOfBoundsException);

@skaffman 2008-10-01 07:24:27

That's what you do in JUnit 3. Junit 4 does it better.

@jontejj 2013-03-14 16:13:37

Also, you won't see what kind of Exception ex is in the test results when the day comes where the test fails.

@Cypher 2018-11-15 00:54:26

This can be improved a bit by changing how you assert at the end. assertEquals(ExpectedException.class, e.getClass()) will show you the expected and actual values when the test fails.

@John Mikic 2013-05-07 17:17:18

You can also do this:

public void testFooThrowsIndexOutOfBoundsException() {
    try {
        assert false;
    } catch (IndexOutOfBoundsException e) {
        assert true;

@NamshubWriter 2015-01-14 04:51:01

In JUnit tests, it's better to use, not assert, just in case your tests run in an environment where assertions are not enabled.

@Macchiatow 2013-07-02 09:03:57

In my case I always get RuntimeException from db, but messages differ. And exception need to be handled respectively. Here is how I tested it:

public void testThrowsExceptionWhenWrongSku() {

    // Given
    String articleSimpleSku = "999-999";
    int amountOfTransactions = 1;
    Exception exception = null;

    // When
    try {
        createNInboundTransactionsForSku(amountOfTransactions, articleSimpleSku);
    } catch (RuntimeException e) {
        exception = e;

    // Then
    shouldValidateThrowsExceptionWithMessage(exception, MESSAGE_NON_EXISTENT_SKU);

private void shouldValidateThrowsExceptionWithMessage(final Exception e, final String message) {

@Daniel Alder 2017-12-18 09:40:15

befor the line with } catch (, you should insert fail("no exception thrown");

@Hugh Perkins 2012-10-10 15:02:44

I tried many of the methods here, but they were either complicated or didn't quite meet my requirements. In fact, one can write a helper method quite simply:

public class ExceptionAssertions {
    public static void assertException(BlastContainer blastContainer ) {
        boolean caughtException = false;
        try {
        } catch( Exception e ) {
            caughtException = true;
        if( !caughtException ) {
            throw new AssertionFailedError("exception expected to be thrown, but was not");
    public static interface BlastContainer {
        public void test() throws Exception;

Use it like this:

assertException(new BlastContainer() {
    public void test() throws Exception {

Zero dependencies: no need for mockito, no need powermock; and works just fine with final classes.

@bln-tom 2014-10-28 21:15:48

Interesting, but doesn't fit to AAA (Arrange Act Assert), where you want to do the Act and the Assert step in actually different steps.

@Trejkaz 2015-02-02 03:52:35

@bln-tom Technically it is two different steps, they're just not in that order. ;p

Related Questions

Sponsored Content

11 Answered Questions

14 Answered Questions

[SOLVED] PHPUnit assert that an exception was thrown?

13 Answered Questions

[SOLVED] How do you test that a Python function throws an exception?

27 Answered Questions

[SOLVED] Maven does not find JUnit tests to run

14 Answered Questions

[SOLVED] How to test that no exception is thrown?

6 Answered Questions

[SOLVED] differences between 2 JUnit Assert classes

22 Answered Questions

1 Answered Questions

[SOLVED] ExpectedException.expectMessage((String) null) is not working

  • 2016-02-04 10:49:14
  • Codebender
  • 1021 View
  • 2 Score
  • 1 Answer
  • Tags:   java junit junit4

1 Answered Questions

[SOLVED] Catch and Re-throw Exceptions from JUnit Tests

  • 2015-03-30 22:45:08
  • ntin
  • 318 View
  • 1 Score
  • 1 Answer
  • Tags:   junit

4 Answered Questions

Sponsored Content