style="font-size:15px;"> ...: 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. We haven’t covered the actions being used in this example, but you don’t need to know what they do in order to see what the error is and how to fix it.
In [65]: out = conn.summary(table=dict(name='test',
....: groupby=['var1', 'var2', 3]))
ERROR: An attempt was made to convert parameter 'table.groupby[2]' from int64 to parameter list, but the conversion failed.
ERROR: The action stopped due to errors.
In the preceding action call, we see that we get an error concerning table.groupby[2]. When you start building parameter structures that are deeply nested, it can be difficult to see exactly what element the message refers to. One of the best tools to track down the error is the cas.trace_actions option. We haven’t reached the section on setting SWAT options, but you can simply submit the following code in order to enable this option:
In [66]: swat.set_option('cas.trace_actions', True)
With this option enabled, we see all of the actions and action parameters printed out in a form that matches the error message from the server. Let’s run the summary action from In[65] again.
In [67]: out = conn.summary(table=dict(name='test',
....: groupby=['var1', 'var2', 3]))
[simple.summary]
table.groupby[0] = "var1" (string)
table.groupby[1] = "var2" (string)
table.groupby[2] = 3 (int64)
table.name = "test" (string)
ERROR: An attempt was made to convert parameter 'table.groupby[2]' from int64 to parameter list, but the conversion failed.
ERROR: The action stopped due to errors.
This time we can see from the printed output that table.groupby[2] is the value 3. According to the definition of the summary action, those values must be strings, so that is the source of the error. We can now go into our action call and change the 3 to the proper value.
If you still do not see the problem, it might be a good idea to separate the parameter construction from the action call as we saw in the section on specifying action parameters. Let’s build the action parameters, one at a time, including the erroneous value.
In [68]: params = swat.vl()
In [69]: params.table.name = 'test'
In [70]: params.table.groupby[0] = 'var1'
In [71]: params.table.groupby[1] = 'var2'
In [72]: params.table.groupby[2] = 3
In [73]: out = conn.summary(**params)
[simple.summary]
table.groupby[0] = "var1" (string)
table.groupby[1] = "var2" (string)
table.groupby[2] = 3 (int64)
table.name = "test" (string)
ERROR: An attempt was made to convert parameter 'table.groupby[2]' from int64 to parameter list, but the conversion failed.
ERROR: The action stopped due to errors.
Of course, in this case the error is pretty obvious since we entered it in a line by itself. But you have parameters that are built in programmatic ways that might not be so obvious. Now our parameters are held in an object that has a syntax that maps perfectly to the output that is created by the cas.trace_actions option as well as the error message from the server. When we see this error message, we can simply display it directly from the params variable to see what the problem is and correct it.
In [74]: params.table.groupby[2]
Out[74]: 3
In [75]: params.table.groupby[2] = 'var3'
Now let’s move on to the remaining class of errors.
Handling Other Errors
All of the other errors that you encounter in SWAT are raised as swat.SWATErrors. Reasons for these errors include the inability to connect to the CAS host, out-of-memory errors, and any other errors that can occur in a networking environment. These can all be handled in the standard Python way of using try/except blocks in your code to capture them.
SWAT Options
As we have seen more than once in this chapter, the cas.exception_on_severity option is one way of changing the behavior of the SWAT package. But there are many others. The options system in SWAT is modeled after the options system in the Pandas package. Most of the function names and behaviors are the same between the two. The primary functions that are used to get, to set, and to query options are shown in the following table.
| Function Name | Description |
| describe_option | Prints the description of one or more options. |
| get_option | Gets the current value of an option. |
| set_option | Sets the value of one or more options. |
| reset_option | Resets the value of one or more options back to the default. |
