[ZEPPELIN-6474] Handle NumberFormatException when parsing MongoDB interpreter numeric properties

[sylee6529]

What is this PR for?

MongoDbInterpreter.open() parses two numeric properties, mongo.shell.command.timeout and mongo.interpreter.concurrency.max, with Long.parseLong() / Integer.parseInt() outside any try/catch — the existing try-with-resources in that method covers only the Scanner that loads the shell extension. When either value is empty, missing, or non-numeric, a raw NumberFormatException escapes open().

Because open() is triggered lazily by the first paragraph run, this lands in the notebook paragraph as a bare stack trace that never names the property at fault. The MongoDB interpreter has several numeric properties, so the only way to tell which one failed today is to read the line number off the trace and open the source — which is not something a Zeppelin user should have to do.

Reproduced on JDK 11: an empty value yields NumberFormatException: For input string: "", a non-numeric value yields For input string: "60s", and a missing property yields a message of just null. One note on that last case — the issue describes it as Cannot parse null string, but that wording comes from newer JDKs. On the JDK 11 this project builds with, Long.parseLong(null) throws NumberFormatException("null"), so the message carries even less information than the issue suggests.

What does this PR do?

• Wraps each parse and re-throws the NumberFormatException as an InterpreterException that names the property and its invalid value, keeping the original exception as the cause:

  Invalid value for property 'mongo.shell.command.timeout': 60s
  

• Keeps the two parses separate so the message always points at the exact property that failed.
• Adds throws InterpreterException to the open() override. The base Interpreter.open() already declares it, so no caller contract changes — at runtime the call goes through LazyOpenInterpreter.open(), which already declares it too, and the only direct caller was the test.

Per the issue, the scope is deliberately narrow: no range validation, no silent fallback to default values, no unrelated changes. An invalid configuration still fails exactly as before; it just fails understandably.

What type of PR is it?

Improvement

What is the Jira issue?

• https://issues.apache.org/jira/browse/ZEPPELIN-6474

How should this be tested?

• ./mvnw test -pl mongodb
• Four tests were added to the existing MongoDbInterpreterTest, covering both properties across the three failure modes named in the issue: non-numeric and missing for mongo.shell.command.timeout, empty and missing for mongo.interpreter.concurrency.max. Each asserts that an InterpreterException is thrown, that its message names the offending property, and that the original NumberFormatException is preserved as the cause. The two remaining combinations exercise the identical catch block, so they were left out rather than duplicated.
• MongoDbInterpreterTest.init() now declares throws InterpreterException, since it calls open() on the concrete type.
• To confirm the new tests are meaningful, I reverted the change to MongoDbInterpreter and re-ran the suite: exactly the four new tests fail with expected: <InterpreterException> but was: <NumberFormatException>, while the two pre-existing tests still pass. With the change applied, all six pass.

Questions:

• Does the license files need to update? No
• Is there breaking changes for older versions? No — a valid configuration behaves exactly as before, and an invalid one already failed. Only the exception type and its message change.
• Does this needs documentation? No