What could be the supervisor the author is referring to?

In the context of the book, the author is referring to the supervisor in Erlang. It handles restart logic for crashing processes, and handles exit messages from their dying processes. The supervisor can then decide what action to take to bring the system back to a stable state.

In Java, I am used to use a lot of try/catch, do I need to stop doing that?

We should avoid abusing try/catch the unexpected exceptions, because it could be unclear if it's safe the program continues. If the program fails later, it may be very difficult to track the root cause.

Taking Java as example, exceptions inheriting from RuntimeException will produce crashes in runtime. For example, try to avoid try/catch but just let the code crash on NullPointerException.

In your code example, the exception is caught, logged, and then rethrown. It is similar in Java where a checked exception can be caught and re-thrown without losing the Stacktrace info (enforced by compiler), for example

try 
{
  //
} 
catch (final SQLException e) 
{
  // logging the error if necessary
  throw new RuntimeException(e);
}

What could be the supervisor the author is referring to?

In the context of the book, the author is referring to the supervisor in Erlang. It handles restart logic for crashing processes, and handles exit messages from their dying processes. The supervisor can then decide what action to take to bring the system back to a stable state. We are allowed to define restart policies on the process there.

Because the supervisors in Erlang manages the processes, we can just let the process crash without affecting anything outside the crashed process, instead of catching the exceptions (and try to address/fix it).

In Java, I am used to use a lot of try/catch, do I need to stop doing that?

We should avoid abusing try/catch the unexpected exceptions, because it could be unclear if it's safe the program continues. If the program fails later, it may be very difficult to track the root cause.

Taking Java as example, exceptions inheriting from RuntimeException will produce crashes in runtime. For example, try to avoid try/catch but just let the code crash on NullPointerException.

In your code example, the exception is caught, logged, and then rethrown. It is similar in Java where a checked exception can be caught and re-thrown without losing the Stacktrace info (enforced by compiler), for example

try 
{
  //
} 
catch (final SQLException e) 
{
  // logging the error if necessary
  throw new RuntimeException(e);
}

What could be the supervisor the author is referring to?

Supervisor in Erlang handles restart logic for crashing processes, and handles exit messages from their dying processes. The supervisor can then decide what action to take to bring the system back to a stable state.

Not sure there is Java feature that works like the Erlang supervisor.

In Java, I am used to use a lot of try/catch, do I need to stop doing that?

Exceptions inheriting from RuntimeException will produce crashes in runtime. For example, try to avoid try/catch but just let the code crash on NullPointerException.

A checked exception can be caught and re-thrown without losing the Stacktrace info (enforced by compiler), for example

try {
  //
} 
catch (final SQLException e) {
  // logging the error if necessary
  throw new RuntimeException(e);
}

What could be the supervisor the author is referring to?

In the context of the book, the author is referring to the supervisor in Erlang. It handles restart logic for crashing processes, and handles exit messages from their dying processes. The supervisor can then decide what action to take to bring the system back to a stable state.

In Java, I am used to use a lot of try/catch, do I need to stop doing that?

We should avoid abusing try/catch the unexpected exceptions, because it could be unclear if it's safe the program continues. If the program fails later, it may be very difficult to track the root cause.

Taking Java as example, exceptions inheriting from RuntimeException will produce crashes in runtime. For example, try to avoid try/catch but just let the code crash on NullPointerException.

In your code example, the exception is caught, logged, and then rethrown. It is similar in Java where a checked exception can be caught and re-thrown without losing the Stacktrace info (enforced by compiler), for example

try  
{
  //
} 
catch (final SQLException e)  
{
  // logging the error if necessary
  throw new RuntimeException(e);
}