Error Handling

All errors⁸encountered 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

... errors⁸

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.