Thanks for catching this!

WebViewChromium.java seems to be only such case, except for VisualStateTest.java.

$ grep -PzoiR "finally {[^}]+return"

returnandroid_webview/javatests/src/org/chromium/android_webview/test/VisualStateTest.java:finally {
                returnandroid_webview/javatests/src/org/chromium/android_webview/test/VisualStateTest.java:finally {
                returnandroid_webview/glue/java/src/com/android/webview/chromium/WebViewChromium.java:finally {
            // The real initialization may be deferred, in which case we don't record this.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/8d96473d6b6ef429cdeeb80ae682e8daa5c74a29

commit 8d96473d6b6ef429cdeeb80ae682e8daa5c74a29
Author: Torne (Richard Coles) <torne@google.com>
Date: Fri Jul 13 16:26:09 2018

Fix incorrect return in finally block losing exceptions.

Returning in a finally block causes exceptions to be discarded. There's
no reason to log a UMA stat for the performance of a startup that threw
an exception (since we're going to crash the app anyway), so just take
it entirely outside the finally block and invert the condition to only
record the UMA stat if mFactory.hasStarted().

Also adjust another place that had the same pattern without the "return"
to match, as again there's no need to log the UMA stat when there's an
exception.

Bug:  862662 
Change-Id: Ie6d24cee5bb9342016c364244256c8b73a8184f7
Reviewed-on: https://chromium-review.googlesource.com/1133332
Commit-Queue: Richard Coles <torne@chromium.org>
Reviewed-by: Tobias Sargeant <tobiasjs@chromium.org>
Cr-Commit-Position: refs/heads/master@{#574941}
[modify] https://crrev.com/8d96473d6b6ef429cdeeb80ae682e8daa5c74a29/android_webview/glue/java/src/com/android/webview/chromium/WebViewChromium.java
[modify] https://crrev.com/8d96473d6b6ef429cdeeb80ae682e8daa5c74a29/android_webview/glue/java/src/com/android/webview/chromium/WebViewChromiumFactoryProvider.java

Requesting merge to 68 - this is a pretty small change and the previous state might be hiding or confusing other problems by swallowing exceptions and making the resulting state hard to debug :(

This bug requires manual review: We are only 10 days from stable.
Please contact the milestone owner if you have questions.
Owners: cmasso@(Android), kariahda@(iOS), bhthompson@(ChromeOS), abdulsyed@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/d1a0e139fb9c107f3c6e3aef5e34b6dbff0c18f3

commit d1a0e139fb9c107f3c6e3aef5e34b6dbff0c18f3
Author: Torne (Richard Coles) <torne@google.com>
Date: Fri Jul 13 19:04:34 2018

Fix incorrect return in finally block losing exceptions.

Returning in a finally block causes exceptions to be discarded. There's
no reason to log a UMA stat for the performance of a startup that threw
an exception (since we're going to crash the app anyway), so just take
it entirely outside the finally block and invert the condition to only
record the UMA stat if mFactory.hasStarted().

Also adjust another place that had the same pattern without the "return"
to match, as again there's no need to log the UMA stat when there's an
exception.

TBR=torne@google.com

(cherry picked from commit 8d96473d6b6ef429cdeeb80ae682e8daa5c74a29)

Bug:  862662 
Change-Id: Ie6d24cee5bb9342016c364244256c8b73a8184f7
Reviewed-on: https://chromium-review.googlesource.com/1133332
Commit-Queue: Richard Coles <torne@chromium.org>
Reviewed-by: Tobias Sargeant <tobiasjs@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#574941}
Reviewed-on: https://chromium-review.googlesource.com/1136871
Reviewed-by: Richard Coles <torne@chromium.org>
Cr-Commit-Position: refs/branch-heads/3440@{#668}
Cr-Branched-From: 010ddcfda246975d194964ccf20038ebbdec6084-refs/heads/master@{#561733}
[modify] https://crrev.com/d1a0e139fb9c107f3c6e3aef5e34b6dbff0c18f3/android_webview/glue/java/src/com/android/webview/chromium/WebViewChromium.java
[modify] https://crrev.com/d1a0e139fb9c107f3c6e3aef5e34b6dbff0c18f3/android_webview/glue/java/src/com/android/webview/chromium/WebViewChromiumFactoryProvider.java

just chatted with torne@ to verify this issue, below is the comment

-----------
if we're going to run the CTS tests before dropping builds as recently discussed in the team meeting then that will verify it
if WebViewDataDirTest#testSameDirTwoProcesses passes then it's working

this is a new test in P so it isn't on any of the chromium dashboards
someone will have to run it manually or else wait until it's dropped into android master so that the android bots test it
----------------