SAS Viya. Kevin D. Smith
in the official SAS Viya documentation on the SAS website.
Dealing with Errors
The issue of CAS action errors was discussed to some extent previously in the chapter. There are two methods for dealing with CAS action errors: return codes and exceptions. The default behavior is to surface return codes, but SWAT can be configured to raise exceptions. In the case of return codes, they are
available in the severity attribute of the CASResults object that is returned by CAS action methods. The possible values are shown in the following table:
| Severity | Description |
| 0 | An action was executed with no warnings or errors. |
| 1 | Warnings were generated. |
| 2 | An error occurred. |
In addition to the severity attribute, the CASResults object has an attribute named reason, which is a string that contains the general reason for the warning or error. The possible reasons are shown in the following table:
| Reason | Description |
| ok | The action was executed with no warnings or errors. |
| abort | The action was aborted. |
| authentication | The action could not authenticate user credentials. |
| authorization | The action was unable to access a resource due to permissions settings. |
| exception | An exception occurred during the execution of an action. |
| expired-token | An authentication token expired. |
| io | An input/output error occurred. |
| memory | Out of memory. |
| network | Networking failure. |
| session-retry | An action restarted and results already returned should be ignored. |
| unknown | The reason is unknown. |
The last two attributes to note are status and status_code. The status attribute of CASResults contains a human-readable formatted message that describes the action result. The status_code is a numeric code that can be supplied to Technical Support if further assistance is required. The code contains information that might be useful to Technical Support for determining the source of the problem.
Using CAS Action Exceptions
As mentioned previously, it is possible for SWAT to raise an exception when an error or warning occurs in a CAS action. This is enabled by setting an option in the SWAT package. We haven’t covered SWAT options yet. It is covered in the next section in this chapter. However, the simplest way to enable exceptions is to submit the following code:
In [62]: swat.options.cas.exception_on_severity = 2
This causes SWAT to throw a swat.SWATCASActionError exception when the severity of the response is 2. For exceptions to be raised on warnings and errors, you set the value of the option to 1. Setting it to None disables this feature.
The swat.SWATCASActionError exception contains several attributes that contain information about the context of the exception when it was raised. The attributes are described in the following table:
| Attribute Name | Description |
| message | The formatted status message from the CAS action. |
| response | The CASResponse object that contains the final response from the CAS host. |
| connection | The CAS connection object that the action was running in. |
| results | The compiled result up to the point of the exception. |
The message attribute is simply the same value as the status attribute of the response. The response attribute is an object that we haven’t discussed yet: CASResponse. This object isn’t seen when using the CAS action methods on a CAS object. It is used behind the scenes when compiling the results of a CAS action. Then it discarded. It is possible to use more advanced methods of traversing the responses from CAS where you deal with CASResponse objects directly, but that is not discussed until much later in this book. For now, it is sufficient to know that the CASResponse object has several attributes, including one named disposition, which contains the same result code fields that the CASResults object also contains.
The connection attribute of swat.SWATCASActionError contains the CAS connection object that executed the action. And finally, the results attribute contains the results that have been compiled up to that point. Normally, this is a CASResults object, but there are options on the CAS action methods that we haven’t yet discussed that cause other data values to be inserted into that attribute.
Catching a swat.SWATCASActionError is just like catching any other Python exception. You use a try/except block, where the except statement specifies swat.SWATCASActionError (or any of its parent classes). In the following code, we try to get help on a nonexistent action. The action call is wrapped in a try/except block in which the except statement captures the exception as the variable err. In the except section, the message attribute of the exception is printed. Of course, you can use any of the other fields to handle the exception in any way you prefer.
In [63]: try:
...: out = conn.help(action='nonexistent')
...: except swat.SWATCASActionError as err:
...: print(err.message)
...:
ERROR: Action 'nonexistent' was not found.
ERROR: The action stopped due to errors.
The specified action was not found.
In addition to CAS action errors, there are other types of errors that you might run into while working with CAS. Let’s look at how to resolve CAS action parameter problems in the next section. But first, let’s reset the exception option back to the default value.
In [64]: swat.options.reset_option('cas.exception_on_severity')
Resolving CAS Action Parameter Problems
CAS action parameter problems can come in many forms: invalid parameter names, invalid parameter values, incorrect nesting of parameter lists, and so on. It can sometimes be difficult to immediately identify the problem. We provide you with some tips in this section that hopefully simplify your correction of CAS action parameter errors.
Let’s start with an action call that creates a parameter error.