Читать книгу SAS Viya - Kevin D. Smith - Страница 30

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')

SAS Viya

Подняться наверх