http://dev.starlink.ac.uk/bugzilla/show_bug.cgi?id=43
Summary: Error status from Starlink apps
Product: MERS
Version: unspecified
Platform: PC
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: MERS
AssignedTo: [log in to unmask]
ReportedBy: [log in to unmask]
QAContact: [log in to unmask]
OK I'm confused (easily done...) about the behaviour of error status in Starlink
apps and what gets returned to the shell. I have an application which is meant
to handle _REAL data but occasionally gets fed _DOUBLE which I want to trap. So
I added the following code to catch this:
call ndf_assoc('CUBE','READ',acundf,status)
call ndf_type(acundf, 'Data', ndftype, status)
write (*,*) 'WASP_SHUTTER DBG: NDF Type of cube is ', ndftype
if ( ndftype .ne. '_REAL' ) then
write (*,*) 'WASP_SHUTTER ERR: Data type of cube is not _REAL. Aborting'
status = NDF__TYPNI
call err_rep('WASP_SHUTTER_ERR', 'WASP_SHUTTER ERR: Data type of' //
& ' cube is not _REAL.', status)
goto 500
endif
When I run this I get the error message I expect but the shell status is 0 and
the calling script carries on incorrectly. When I take this catch out, the
program segfaults but the shell status is now 139 and the script halts as
desired ! Surely this can't be the correct way of programming things ? I have
looked in SC12 and SUN104 but haven't achieved enlightenment... What's the
correct way of getting a non-zero status back to the shell in the event of an
error ?
Cheers,
Tim
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
You are the QA contact for the bug, or are watching the QA contact.
|