Error exception ioexception is never thrown in body of corresponding try statement

«Exception is never thrown in body of corresponding try statement.» When does this error occur?

I got the Compiler error «IOException is never thrown in body of corresponding try statement» for the below code. But I have got no error when I caught «NumberFormatException» instead of «IOException». When does this error occur? And when does it not??

public class abc
<

public static void main(String args[]) throws Exception
<
try
<
System.out.println(«Try «);
>
catch (IOException e) <>
finally
<
System.out.println(«Finally «);
>
>
>

Thank you,
Bindu.

IOException can never occur from System.out.println(). But NUmberFormatException can occur in the following case :

I hope this clears your doubt.

If the underlying stream is a socket stream and the network dies while you’re reading, if you’re attempting to read from a stream that’s been closed, etc.There are many instances where the IOException will be raised. If you want to raise the IOException you can do it explicitly by using keyword throw.Look at the following code which will throw the IOException explicitly.

Thank you Koushik and James.

What I understood is that, Compiler does not generate an Error if we try to catch an Exception that might possibly be thrown in the try block. But if there is absolutely no possibility of that Exception occurring in the try block, then the Compiler would complain.

I guess an empty try block guarantees no exceptions, whatsoever. In this case, compiler should complain if we try to catch any kind of Exception. But, I still see no error in case of NumberFormatException and error in case of IOException. Why is this discrepancy?

>
catch (NumberFormatException e) <>

Thank you,
Bindu.

Bindu Tadivaka wrote: Thank you Koushik and James.

What I understood is that, Compiler does not generate an Error if we try to catch an Exception that might possibly be thrown in the try block. But if there is absolutely no possibility of that Exception occurring in the try block, then the Compiler would complain.

I guess an empty try block guarantees no exceptions, whatsoever. In this case, compiler should complain if we try to catch any kind of Exception. But, I still see no error in case of NumberFormatException and error in case of IOException. Why is this discrepancy?

The compiler only error checks checked exceptions — hence, the name. IOException is a checked exception. NumberFormatException is an unchecked exception.

Источник

exception java.lang.InterruptedException is never thrown in body of corresponding try statement

Any idea why I am getting a compilation error, and, how I could go about it?

Source Core Java Vol.2 (7th Ed.) written for JDK 1.5.

Error java:52: exception java.lang.InterruptedException is never thrown in body of corresponding try statement catch (InterruptedException e)

Read the error message from the compiler carefully.

What do you think it is trying to tell you?

John Jai wrote: Were you able to figure out the source of error in the below code?

Well is it safe to remove the catch? In any case the ‘ball’ does not seem to move anywhere with this code, when I remove the catch clause.

Jon Camilleri wrote: Well is it safe to remove the catch? In any case the ‘ball’ does not seem to move anywhere with this code, when I remove the catch clause.

So, let’s look at the error message from the compiler:

exception java.lang.InterruptedException is never thrown in body of corresponding try statement catch (InterruptedException e)

Read it carefully and try to understand it. What does it say? It says that in the try-block there isn’t any code that can ever throw InterruptedException. In other words, catching InterruptedException is unnecessary here, because it will never be thrown from the try-block.

So, what do you think, is it safe to remove the catch?

Jon Camilleri wrote: Well is it safe to remove the catch? In any case the ‘ball’ does not seem to move anywhere with this code, when I remove the catch clause.

So, let’s look at the error message from the compiler:

exception java.lang.InterruptedException is never thrown in body of corresponding try statement catch (InterruptedException e)

Read it carefully and try to understand it. What does it say? It says that in the try-block there isn’t any code that can ever throw InterruptedException. In other words, catching InterruptedException is unnecessary here, because it will never be thrown from the try-block.

So, what do you think, is it safe to remove the catch?

Horstmann reads that the catch is recommended to be there, whilst the compiler thinks that it is not.

Источник

компилятор java говорит, что это исключение никогда не выбрасывается в теле соответствующего оператора try-но оно выбрасывается

у меня есть следующий код:

когда выше запускается с неправильным именем хоста, я получаю:

это правильно и ожидается. Я переписал код, чтобы специально поймать UnknownHostException, следующим образом:

однако, когда я пытаюсь скомпилировать это, я получаю:

это явно ложно, так как исключение брошено, как я поймал его раньше. Я что-то упускаю?

5 ответов

это не бросать UnknownHostException . Он просто появляется в исключения, вы на самом деле поймали. Вероятно, это основная причина исключения, которое вы поймали.

определить фактический исключение, вы должны напечатать немного больше деталей. Е. Г.

или просто с помощью Throwable#toString() , которая уже включает в себя как тип исключения и сообщение:

или просто передать исключение в качестве 2-й аргумент logger, если хорошо настроен, его stacktrace будет напечатан:

обновление в соответствии с вашими комментариями: лучше всего обновить улов следующим образом:

вы абсолютно не должны различать на основе сообщения. Это проблема переносимости. Сообщение является чувствительной темой для изменений, которые могут даже зависеть от локали!

существуют различные тонкие (или в некоторых случаях неубедительные) способы создания проверенных исключений в ситуациях, когда они явно не объявлены. Некоторые перечислены на этой странице.

просто мысль, может быть, это UnknownHostException в другой упаковке?

e.getMessage () дает вам вывод, указывающий, что UnknownHostException происходит где-то, но, возможно, код за портом.login () somewhere ловит UnknownHostException ,бросая другое исключение и указывая в сообщении этого исключения, что UnknownHostException было исходным исключением (или, возможно, его цепочкой). Трудно сказать, не зная, какой точный тип исключения пойман в вашем оригинальном блоке catch. Узнайте это сначала (возможно, просто сделав е.печатные() ) и это должно сказать вам, что вы должны ловить.

на android я видел это, но на самом деле это проходило как UndeclaredThrowableException . Так что вместо того, чтобы ловить UnknownHostException , Я только что поймал UndeclaredThrowableException .

Источник

1. Overview

In this tutorial, we’ll look at the Lombok @SneakyThrows annotation.

2. Maven Dependency

We’ll first add the Lombok maven dependency:

<dependency>
    <groupId>org.projectlombok</groupId>
    <artifactId>lombok</artifactId>
    <version>1.18.8</version>
</dependency>

3. Use @SneakyThrows

Java requires that we must either declare or handle a checked exception. Otherwise, the code won’t compile. But @SneakyThrows lets us bypass this rule.

For instance, when we call a method that throws an IOException, we must either declare the IOException in our own method:

public void throwsCheckedAndDeclares() throws IOException {
    throw new IOException("Checked exception");
}

Or we must handle it with a try-catch block:

public void throwsCheckedAndHandles() {
    try {
        throw new IOException("Checked exception");
    } catch (IOException e) {
        System.out.println(e.getMessage());
    }
}

Note that this rule is only valid for checked exceptions. We don’t need to handle or declare unchecked exceptions:

public void throwsUncheckedAndSkips() {
    throw new RuntimeException("Unchecked exception");
}

Here, we’re throwing RuntimeException which is an unchecked exception.

Now that we’ve seen the regular usage, let’s look at the usage of @SneakyThrows:

@SneakyThrows
public void sneakyThrowsCheckedAndSkips() {
    throw new IOException("Checked exception");
}

Although we throw an IOException here, we aren’t declaring or handling. @SneakyThrows fakes out the compiler. In other words, Lombok doesn’t wrap or replace the thrown checked exception but makes the compiler think that it is an unchecked exception.

Let’s see another way to achieve the same result:

public void sneakyThrowsCheckedAndSkipsWithLombok() {
    try {
        throw new IOException("Checked exception");
    } catch (IOException e) {
        Lombok.sneakyThrow(e);
    }
}

In this code, we’re catching the IOException and calling Lombok.sneakyThrow. In return, it just throws the same exception without any modification.

This is possible because JVM isn’t aware of the distinction between checked and unchecked exceptions. Moreover, it doesn’t enforce the handle-or-declare rule. This rule is enforced by the Java compiler. Consequently, when we deceive the Java compiler, our code just runs fine.

We generally catch a checked exception and wrap it inside a RuntimeException, and then throw it. @SneakyThrows reduces the number of this pattern, as a result, making the code more readable.

3.1. Configure Exception Types

We can also configure the exception types that we want to sneakily throw, in the value attribute of @SneakyThrows.

@SneakyThrows({IOException.class, ParseException.class})
public void filtersExceptions(String fileName) {
    if (fileName.startsWith("0")) {
        throw new ParseException("test", 1);
    } else {
        throw new IOException();
    }
}

The important point here is that if we list an exception that can’t be thrown from the method body, the code won’t compile.

3.2 Implications of Using @SneakyThrows

We can’t catch sneakily thrown checked exceptions directly. This is because the Java compiler expects the exception type declared as thrown in one of the invoked methods.

Let’s see with an example.

Previously, we defined the sneakyThrowsCheckedAndSkips method. When we call it from another method and try to catch IOException:

public void callSneakingThrowingChecked() {
    try {
        sampleService.sneakyThrowsCheckedAndSkips();
    } catch (IOException e) { // java: exception java.io.IOException is never thrown in body of corresponding try statement
        System.out.println(e);
    }
}

The compiler says that «java.io.IOException is never thrown in body of corresponding try statement«. Although sneakyThrowsCheckedAndSkips throws IOException, the compiler isn’t aware of it. Hence the compilation fails.

As a workaround, we can use a parent type — like Exception — in the catch block:

public void callSneakingThrowingChecked() {
    try {
        sampleService.sneakyThrowsCheckedAndSkips();
    } catch (Exception e) {
        System.out.println(e);
    }
}

After this change, the code compiles and the calling code can catch the sneakily thrown IOException.

4. Global Configuration

Lombok provides some configuration keys for the annotations to globally configure them.

4.1. lombok.sneakyThrows.flagUsage

We can set the lombok.sneakyThrows.flagUsage property to forbid the use of @SneakyThrows:

# [warning | error] (default: not set)
lombok.sneakyThrows.flagUsage = error

There is no default value for this property, and we’re setting it as error. As a result, when Lombok detects usage of @SneakyThrows, it prints an error message like «Use of @SneakyThrows is flagged according to lombok configuration.«

5. Summary

In this tutorial, we’ve investigated the usage of Lombok @SneakyThrows.

As always, the source code for all examples is available on Github.

Welcome to the Treehouse Community

The Treehouse Community is a meeting place for developers, designers, and programmers of all backgrounds and skill levels to get support. Collaborate here on code errors or bugs that you need feedback on, or asking for an extra set of eyes on your latest project. Join thousands of Treehouse students and alumni in the community today. (Note: Only Treehouse students can comment or ask questions, but non-students are welcome to browse our conversations.)

Looking to learn something new?

Treehouse offers a seven day free trial for new students. Get access to thousands of hours of content and a supportive community. Start your free trial today.