Error Handling

All errors8encountered during execution of labCA calls result in the call being aborted, a message being printed to the console and an error status being recorded which can be retrieved using scilab's lasterror command. The recommended method for handling errors is scilab's try – catch – end construct:
	try
		val = lcaGet(pvvector)
	catch
		err   = lasterror()
		// additional information is provided
		// by the 'lcaLastError' routine
		stats = lcaLastError()
		// handle error here
	end
Many labCA calls can handle multiple PVs at once and underlying CA operations may fail for a subset of PVs only. However, lasterror only supports reporting a single error status. Therefore the lcaLastError routine was implemented: if a labCA call fails for a subset of PVs then a subsequent call to lcaLastError returns a column vector of status values for the individual PVs. The error codes are shown in Table 1.


Table 1:  labCA error codes. Numerical codes (scilab lasterror and lcaLastError()) and corresponding matlab error “ID”s (as returned by matlab lasterror).
# Matlab Error ID Comment
0 labca:unexpectedOK No error
1 labca:invalidArg Invalid argument
2 labca:noMemory Not enough memory
3 labca:channelAccessFail Underlying CA operation failed
4 labca:udfCaReq Item(s) requested undefined for its/their native data type
5 labca:notConnected Channel currently disconnected
6 labca:timedOut No response in time
7 labca:inGroup Currently in a EZCA group
8 labca:notInGroup Currently not in a EZCA group
9 labca:usrAbort EZCA call aborted by user (Ctrl-C)
20 labca:noMonitor No monitor for PV/type found
21 labca:noChannel No channel for PV name found





Footnotes

... errors8
As of version 3; earlier versions didn't consistently “throw” all errors so that they could be caught by the try-catch-end mechanism but would merely print messages when encountering some minor errors. Also, versions earlier than 3 would not report error IDs/messages to lasterror nor implement the lcaLastError routine.