CL condition system is based on error handlers, which is the 3rd paradigm aside from returning error values and exceptions. Unfortunately, it didn't really permeate the Unix based languages (C, C++, Java), because Unix had completely kneecapped implementation of error handlers in the OS (lack of user defined signals and their hierarchy). Error handlers are so much underrated that even books like Code Complete do not mention them.

Each of the three paradigms has pros and cons in terms of code simplicity and runtime cost (in normal/error path), I don't think there is a clear winner.

Java has them now but it didn't at the time (and even now they're kind of bodged in IIRC).

I don't think Java has support for CL condition system-style restarts. You're maybe talking about exceptions that simply don't populate the stack trace?

To clarify a bit, in CL, when throwing an exception, you can optionally register one or more "restarts", which are essentially lambdas of 0 or more parameters. When the exception is thrown, the stack is walked to find the appropriate handler, but it is not unwound. Whoever catches the exception will also receive these restart lambdas. If they chose to call one of the lambdas (passing it the proper parameters), stack unwinding will not happen at all, and execution will continue from the place the exception was thrown. Only if none of the restarts are invoked is the stack unwound, and execution continued from the catch block.

For a somewhat trivial example, the CL runtime throws an exception whenever a variable that was not defined is being read. That exception includes a restart that allows you to define a value for the variable - if this is called, execution will continue where the variable was being read, using this value for the undefined variable. Of course, this would be crazy to do automatically, but it is very nifty when debugging, as this option is presented to you in the REPL.

Pretty sure GP was talking about first-class functions not condition-system &c.