We help IT Professionals succeed at work.

Is there anything in cygwin bash that is similar to try-catch in C++?

ilyaz
ilyaz asked
on
Medium Priority
1,339 Views
Last Modified: 2013-11-15
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.
Comment
Watch Question

Top Expert 2006

Commented:
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.
Duncan RoeSoftware Developer
CERTIFIED EXPERT

Commented:
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
Artysystem administrator
Top Expert 2007

Commented:
'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
...

Author

Commented:
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.
system administrator
Top Expert 2007
Commented:
Then you can't collect exit statuses of individual programs, Im sorry...

Anyway you cannot stop currently executing program from outside (from bash) when some (internal to that program) condition occurs,
unless it's being debugged or traced.

Ok, I have an idea how to debug executing program, but it will be a hack.
The hack is: you can write your own program that will run this 'black box' with tracing turned on. There is a ptrace() syscall for doing this.
It's quiet complex but not impossible :)

Also you can collect 'post results' of such execution (including system() and exit statuses) by
'strace -o logfile your_progname' command. Where you can see which program has finished incorrectly.


Not the solution you were looking for? Getting a personalized solution is easy.

Ask the Experts
Duncan RoeSoftware Developer
CERTIFIED EXPERT

Commented:
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.
Artysystem administrator
Top Expert 2007

Commented:
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.
Access more of Experts Exchange with a free account
Thanks for using Experts Exchange.

Create a free account to continue.

Limited access with a free account allows you to:

  • View three pieces of content (articles, solutions, posts, and videos)
  • Ask the experts questions (counted toward content limit)
  • Customize your dashboard and profile

*This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

OR

Please enter a first name

Please enter a last name

8+ characters (letters, numbers, and a symbol)

By clicking, you agree to the Terms of Use and Privacy Policy.