ilyaz
asked on
Is there anything in cygwin bash that is similar to try-catch in C++?
I am running a command-line app that is nothing more than a script-like executible that calls several other stand-alone apps one after another. Each of these apps takes the output of the previous one as input and generates its own output. One of the intermediate apps crashes from time to time. This causes two types of behavior. If a certain file that this app is supposed to create exists (e.g. from a previous run of this app) then then next app in the pipeline proceeds thus generating garbage results that look credible, which is bad. If the file does not exist then the next app freezes, which is equally bad. I need to try to catch the crash and stop the main app before it proceeds to the next step after the crash. Do you know if there are any utilities in bash that could help me with this?
Note that handling the return code of the main app does not help: it's normal in the case the main app generates garbage and I can't get it if the app freezes. And I also don't have access to the return codes of the individual apps because they are called from within the main app. Finally, the main app is a binary exe file as opposed to a human-readable script file, so I have no way of modifying it.
One workaround for the case when the program freezes is to run it with something like 'expect' and kill it after a certain maximum amount of time. This is not very elegant and may not in certain cases, so I am looking for alternatives.
Note that handling the return code of the main app does not help: it's normal in the case the main app generates garbage and I can't get it if the app freezes. And I also don't have access to the return codes of the individual apps because they are called from within the main app. Finally, the main app is a binary exe file as opposed to a human-readable script file, so I have no way of modifying it.
One workaround for the case when the program freezes is to run it with something like 'expect' and kill it after a certain maximum amount of time. This is not very elegant and may not in certain cases, so I am looking for alternatives.
pjedmond
Unfortunately not as bash is a scripting language. The approach that you've suggested using expect, or running the process, and using another process to check whether the thread has returned are probably the only approach available in bash....BUT you could put a C++ wrapper around the command in order to use try and catch.
I would have suggested expect but you already mentioned it. But why not run the potentially crashing program under expect - then you could take action on a crash.
A simpler idea: delete any file remaining from a previous run of the potentially crashing app before running that app. Check for the existence of that file before running the next app. You can do all that from bash
A simpler idea: delete any file remaining from a previous run of the potentially crashing app before running that app. Check for the existence of that file before running the next app. You can do all that from bash
'Each of these apps takes the output of the previous one as input and generates its own output.'
Do you mean pipelined call like 'app1 | app2 | app3 | ...'
or just sequential execution:
app1
app2
app3
If you have sequential execution, you may exit on error very easy (if 0 is a normal return code and nonzero or crash by signal is a failure):
app1 || exit
app2 || exit
If you have pipelined execution then you cannot analize 'previous' because all applications are stared simultaneously. And then it's only your application's responsibility to analize some specific files before reading stdin.
However you may unroll your 'pipelined' form to 'sequential' like this:
app1 > file1 || exit
app2 < file1 > file2 || exit
...
Do you mean pipelined call like 'app1 | app2 | app3 | ...'
or just sequential execution:
app1
app2
app3
If you have sequential execution, you may exit on error very easy (if 0 is a normal return code and nonzero or crash by signal is a failure):
app1 || exit
app2 || exit
If you have pipelined execution then you cannot analize 'previous' because all applications are stared simultaneously. And then it's only your application's responsibility to analize some specific files before reading stdin.
However you may unroll your 'pipelined' form to 'sequential' like this:
app1 > file1 || exit
app2 < file1 > file2 || exit
...
ASKER
As I said before: "And I also don't have access to the return codes of the individual apps because they are called from within the main app. Finally, the main app is a binary exe file as opposed to a human-readable script file, so I have no way of modifying it." I guess that this is a C program that has a sequence of system() calls that invoke app1, app2 etc. These apps comminucate with each other through the temporary files.
So to summarize: no, this is not a pipelined execution in the strict UNIX sense of the term. Yes, this is a sequential execution, but I don't have access to return codes of app1, app2 etc.
So to summarize: no, this is not a pipelined execution in the strict UNIX sense of the term. Yes, this is a sequential execution, but I don't have access to return codes of app1, app2 etc.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Something else you might be able to do is rename the apps that your program runs (add .exe to each of their names for instance) and have shell scripts in their place which run the apps if all is well.
Only likely problem that I can see is if the child apps expect file units to be opened for them by the parent - could be managed maybe.
Only likely problem that I can see is if the child apps expect file units to be opened for them by the parent - could be managed maybe.
ilyaz, duncan_roe said a good deal.
When you have strace output, look for 'execve()' syscalls, find all programs,
that your applicaiton launches and then create shell wrappers instead of that programs.
Shell wrapper will run real application and may analyse if some file presents or if application terminated abnormally.
Also wrapper may kill it's parrent, so main application execution will be terminated on error condition.
When you have strace output, look for 'execve()' syscalls, find all programs,
that your applicaiton launches and then create shell wrappers instead of that programs.
Shell wrapper will run real application and may analyse if some file presents or if application terminated abnormally.
Also wrapper may kill it's parrent, so main application execution will be terminated on error condition.