Java执行'catch'块没有错误，并且仍以某种方式运行'try'块

Question

I have a problem with the following code. First, I am a newbie to Java with experience with several other languages.

When I run the following on Android, it errors at "in.close();", jumps to the catch block and runs Return ""; The thing is, the function doesn't return an empty string, it successfully returns the correct json data even though the debugger says it isn't running return json, but that it's running return "";

public void fetch() {

    // Get the JSON of the image gallery
    String json = getJSON();

    // json somehow has the actual correct json data and not an empty string!

};

private String getJSON() {

    try {
        // Create a URL for the desired page
        URL url = new URL("http://imgur.com/gallery.json");

        // Read all the text returned by the server
        BufferedReader in = new BufferedReader(new InputStreamReader(url.openStream(), "UTF-8"));
        String json = in.readLine();
        in.close();
        return json; // <-- debugger doesn't break here!
    }
    catch(Exception e) {
        Log.e("getJSON", e.getMessage());
        return ""; // <-- debugger breaks here! Cat Log shows nothing!
    }
}

I copy the exact same code into a Java console so that I can output the error message and watch it in the debugger with break points, and the code executes without error.

    try {
        // Create a URL for the desired page
        URL url = new URL("http://imgur.com/gallery.json");

        // Read all the text returned by the server
        BufferedReader in = new BufferedReader(new InputStreamReader(url.openStream()));
        String json = in.readLine();
        in.close();
        System.out.println(json);
}
catch(Exception e) {
    System.out.println(e.getMessage());
}   

What exactly is going on? Why is my code run on Android erroring when it runs in a Java Console just fine? Why when it errors does it not return what the error is supposed to return; and empty string? How can I view the error message in Android?

Answer 1

You should make sure to include the

<uses-permission android:name="android.permission.INTERNET" />

permission in your androidManifext.xml .

You are trying to retrieve data from a remote location. On Java console you can do it without such permissions, but not in Android.

Answer 2

Forget about "System.out.println" in Android. You can use "Logcat" view in Eclipse. This is used to show every log you want from your device. Also, you can replace " System.out.println(json); " by " Log.e("MyApp", "Here is my Json: '"+json+"'"); " and you'll see your json in the logcat... ;)

About your exception, you have a method in the frameworkthat automatically logs the exceptions in the logcat: " myException.printStackTrace(); "

Answer 3

A Reader reads text, an InputStream binary data. The bridge InputStreamReader needs a character encoding, and takes in your case the default OS encoding.

So better explicitly use an encoding:

BufferedReader in = new BufferedReader(new InputStreamReader(url.openStream(), "UTF-8"));

As JSON should better be in UTF-8, I have given that. But the default encoding on Android is UTF-8 and with you probably Cp1252. So there might be something else wrong too.

Answer 4

Your code appears to be correct. If you did see a JSON returned, then you were not getting any IOException from close .

Edit :

Your updated source code clearly shows that there is no return from finally or retry logic in play here. Good.

Visit the following setting in your environment: Window / Preferences / Run/Debug / Launching / "Launch in debug mode when workspace contains breakpoints"

Set this to Always or Prompt . (If it was previously Never , you might have been running in Run mode, thus employing optimizations you did not want. The two return statements may have been combined into one by the optimizer.) After you change this setting, you should never see a breakpoint hit at a line different from the line on which it was set. Please double check your findings with the new setting.

There is also an alternate way of breaking on exceptions (Suspend On Caught Exceptions) that is immune to this kind of optimization, if for any reason you do not want to run in debug mode.