Remove warning from catch in table exists validation

[damondouglas]

This PR addresses #28080 by refactoring the catch block during BigtableIO table existence validation.

---

Thank you for your contribution! Follow this checklist to help us incorporate your contribution quickly and easily:

• Mention the appropriate issue in your description (for example: addresses #123), if applicable. This will automatically add a link to the pull request in the issue. If you would like the issue to automatically close on merging the pull request, comment fixes #<ISSUE NUMBER> instead.
  Update CHANGES.md with noteworthy changes.
  If this contribution is large, please file an Apache Individual Contributor License Agreement.

See the Contributor Guide for more tips on how to make review process smoother.

To check the build health, please visit https://github.com/apache/beam/blob/master/.test-infra/BUILD_STATUS.md

GitHub Actions Tests Status (on master branch)

See CI.md for more information about GitHub Actions CI or the workflows README to see a list of phrases to trigger workflows.

[github-actions]

Checks are failing. Will not request review until checks are succeeding. If you'd like to override that behavior, comment assign set of reviewers

[damondouglas]

assign set of reviewers

[github-actions]

Assigning reviewers. If you would like to opt out of this review, comment assign to next reviewer:

R: @robertwb for label java.
R: @chamikaramj for label io.

Available commands:

• stop reviewer notifications - opt out of the automated review tooling
• remind me after tests pass - tag the comment author after tests pass
• waiting on author - shift the attention set back to the author (any comment or push by the author will return the attention set to the reviewers)

The PR bot will only process comments in the main thread (not review comments).

[Abacn]

from the existing warning message "proceeding" this sounds intended. throw an exception may introduce breaking change R: @mutianf

[github-actions]

Stopping reviewer notifications for this pull request: review requested by someone other than the bot, ceding control

[mutianf]

This is meant to catch exceptions when something went wrong and Bigtable client can't connect to the server. In this case we don't know for sure if the table exist or not (note that when the table doesn't exist the code will throw an error on line 695). So I'm not sure if throwing an exception is the right behavior here. But I don't think this will be a breaking change.

[mutianf]

Can you make the exception more descriptive? Or log the error first? I also think we should re-throw IOException instead of changing it to a IllegalArgumentException because it's not an issue with the argument.

[damondouglas]

@mutianf Thank you again for your review and comments. Given the following, do you feel comfortable with the code changes?

1. We cannot throw an IOException as the overridden public void validate(PipelineOptions options) method cannot also throw this IOException. Therefore, we have to use a subclass of the RuntimeException, hence the use of IllegalArgumentException. The other choice would just be a RuntimeException. However, it seems to make sense that the arguments provided led to the Exception thrown.

2. The BigtableServiceFactory's checkTableExists already provides detail on the tableId and the originating ApiException. Therefore, the throw new IllegalArgumentException(e) would capture these details already.

In summary, I see the following scenarios:

Scenario	Exception Message	Code Origin
Not Found ApiException	Table <> does not exist	BigtableServiceFactory.java:206
ApiException	"Error checking whether table <> exists" with ApiException details	BigtableServiceFactory.java:210