Project

General

Profile

Bug #1690

better exception handling when OS libraries are not found by P2J

Added by Constantin Asofiei over 11 years ago. Updated over 11 years ago.

Status:
New
Priority:
Normal
Target version:
-
Start date:
Due date:
% Done:

0%

billable:
No
vendor_id:
GCD
case_num:
version:

History

#1 Updated by Constantin Asofiei over 11 years ago

I found at least one case when P2J did not report correctly that the libp2j.so was not found. The problem appeared when the code needed to read some data from a process output, using the unnamed streams. The client ended up with a "Attempt to read from closed stream" error message when the code tried to read data from the process output, as libp2j.so was missing.

When ProcessOps.launch is called, on the client side ends up calling the ProcessDaemon.launch method. This, in turn, relies on a native method call, LaunchManager.pseudoTerminalLaunch, to launch the process. An exception was being thrown when the call failed, but this exception was not handled or logged by the client (I think the client just ignores it). These kind of exceptions need to be caught, logged on the client-side and a StopConditionException should be thrown from the client (so the server ends current processing). A message needs to be displayed on the terminal before throwing the exception.

#2 Updated by Greg Shah over 11 years ago

Optimally, we should detect a failure to load libTerminal.so or libp2j.so as soon as we attempt to load the library. Any failure should be detected and reported to make the problem cause clear to the user.

If this occurs in response to converted 4GL code running, then Constantin's idea of a STOP exception (with a proper message) is the right approach.

If this occurs before converted 4GL code can run (which is probably the case for a libTerminal.so failure), then it may be more tricky to resolve as a STOP condition may not be the right approach. Please note that the client in this case normally cannot do logging to STDOUT but only to STDERR. Often STDERR is redirected to a log file and STDOUT is expected to be captured by NCURSES (which occurs during libTerminal.so init. If the STDOUT is not captured yet, then perhaps printing a message to there is fine.

Also available in: Atom PDF