Is this try catch block enough to ensure the process ran successfully?

protected boolean attemptLaunch()
    {
        try
        {
            System.out.println("Attempting to open '" + name + "'.");

            //Try to open the Process
            new ProcessBuilder(path).start();

            return true;
        }
        catch (IOException e)
        {
            System.out.println("Opening failed. Will retry during next Iteration.");
            return false;
        }
    }

Dani AI

Generated

Short answer: the try/catch only proves that the JVM successfully invoked ProcessBuilder.start() — not that the launched program actually ran correctly or stayed running. That distinction was already touched on by , and ; the next step is to turn that observation into a reliable verification strategy.

Capture the Process and gather evidence of readiness instead of returning true on start(). Common patterns:

  • Keep the returned Process object and never ignore its streams (stdout/stderr) or the process can block on full buffers.
  • Redirect or consume output asynchronously and look for a definite "ready" marker, or poll a health port/socket the child opens.
  • Use a timed wait for termination and check the exit value if the program is expected to finish, or use isAlive()/ProcessHandle.onExit() for long-running processes.

Example pattern (compact):

CountDownLatch ready = new CountDownLatch(1);
ProcessBuilder pb = new ProcessBuilder("myApp");
pb.redirectErrorStream(true);
Process p = pb.start();

new Thread(() -> {
  try (BufferedReader r = new BufferedReader(new InputStreamReader(p.getInputStream()))) {
    String line;
    while ((line = r.readLine()) != null) {
      System.out.println(line);
      if (line.contains("READY")) ready.countDown();
    }
  } catch (IOException ignored) {}
}).start();

boolean serviceReady = ready.await(5, TimeUnit.SECONDS);
if (!serviceReady && !p.isAlive()) {
  // start failed or crashed — treat as failure
}

Design notes and troubleshooting tips:

  • If the target app detaches (GUI or launcher), a wrapper or explicit readiness signal is needed because the parent process may exit immediately.
  • For batch tools rely on exit codes; for services prefer a health-check endpoint or a "pid/ready" file.
  • For long-running processes consider redirecting output to files or using an ExecutorService to consume streams, and always handle InterruptedException properly.

Returning true just because start() threw no IOException is insufficient. A robust check requires either a protocol-level readiness signal or observable, program-specific evidence that the process is functioning.

Recommended Answers

All 3 Replies

I think that will catch problems where the OS was not able to load and start the process. I think it will not catch any problems that the new process encounters(eg invalid run parameter values) after it starts to execute.
So, you asked two questions:
"Relying on Try-Catch enough to ensure the Process was successfully started?"
Yes
"Is this try catch block enough to ensure the process ran successfully?"
No

I agree with James. It just catches what you set it to catch. Runtime errors should be handled separately..

It ONLY catches IO errors, which probably means it only catches problems opening the file that starts the process.
It can't possibly catch problems happening at runtime, process crashes, process failing to run because the executable is corrupt, security problems, etc. etc.
For those you'll need to do other things.
Things like monitoring the process's output and error streams of the Process returned by the ProcessBuilder.

There's more information in the javadoc for Process and ProcessBuilder.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.