support counter error handler name for cross-compatibility

driver-cql-shaded/src/main/java/io/nosqlbench/activitytype/cql/api/ErrorResponse.java

@@ -13,9 +13,10 @@ public enum ErrorResponse {
     retry("R"),     // resubmit this operation up to the available tries
     histogram("H"),     // record this metric in a histogram
     count("C"),     // count this metric separately
+    counter("C"),
     ignore("I");    // do nothing
 
-    private String symbol;
+    private final String symbol;
 
     ErrorResponse(String symbol) {
         this.symbol = symbol;

driver-cql-shaded/src/main/java/io/nosqlbench/activitytype/cql/errorhandling/NBCycleErrorHandler.java

@@ -82,6 +82,7 @@ public class NBCycleErrorHandler implements CycleErrorHandler<Throwable, ErrorSt
             case histogram:
                 exceptionHistoMetrics.update(error,cce.getDurationNanos());
             case count:
+            case counter:
                 exceptionCountMetrics.count(error);
             case ignore:
             default:

driver-cql-shaded/src/main/resources/cql-errors.md

@@ -61,56 +61,59 @@ When an error occurs, you can control how it is handled for the most part.
 This is the error handler stack:
 
 - **stop** - logs an error, and then rethrows the causing exception,
-    causing nosqlbench to shutdown the current scenario.
+  causing nosqlbench to shutdown the current scenario.
-- **warn** - log a warning in the log, with details about the error 
+- **warn** - log a warning in the log, with details about the error and
-    and associated statement.
+  associated statement.
 - **retry** - Retry the operation if the number of retries hasn't been
-    used up *and* the causing exception falls in the set of
+  used up *and* the causing exception falls in the set of
-    *retryable* errors.
+  *retryable* errors.
-- **histogram** - keep a histogram of the exception counts, under the
+- **histogram** - keep a histogram of the exception counts, under the name
-    name errorhistos.classname, using the simple class name.
+  errorhistos.classname, using the simple class name. The magnitude of
-    The magnitude of these histos is how long the operation was pending
+  these histos is how long the operation was pending before the related
-    before the related error occurred.
+  error occurred.
 - **count** - keep a count in metrics for the exception, under the name
-    errorcounts.classname, using the simple class name.
+  errorcounts.classname, using the simple class name.
+- **counter** - same as **count**, added for compatibility with the newer
+  universal error handler. This one is the preferred name.
 - **ignore** - do nothing, do not even retry or count
 
 Each handling verb above is ordered from the most invasive to least
-invasive starting at the top.  With the exception of the **stop** 
+invasive starting at the top. With the exception of the **stop**
-handler, the rest of them will be applied to an error all the way 
+handler, the rest of them will be applied to an error all the way to the
-to the bottom. For now, the error handling stack is exactly as above. 
+bottom. For now, the error handling stack is exactly as above. You can't
-You can't modify it, although it may be made configurable in the future.
+modify it, although it may be made configurable in the future.
 
-One way to choose the right handler is to say "How serious is this type
+One way to choose the right handler is to say "How serious is this type of
-of error to the test results if it happens?" In general, it is best 
+error to the test results if it happens?" In general, it is best to be
-to be more conservative and choose a more aggressive setting unless you 
+more conservative and choose a more aggressive setting unless you are
-are specifically wanting to measure how often a given error happens, 
+specifically wanting to measure how often a given error happens, for
-for example.
+example.
 
 Each exception type will have one and only one error handler at all times.
-No matter how you set an error handler for a class, only the most
+No matter how you set an error handler for a class, only the most recently
-recently assigned handler stack will be active for it. This might be
+assigned handler stack will be active for it. This might be important to
-important to keep in mind when you make multiple assignments to potentially
+keep in mind when you make multiple assignments to potentially overlapping
-overlapping sets of error types. In any case, the default 'stop' handler
+sets of error types. In any case, the default 'stop' handler will always
-will always catch an error that does not otherwise have a more specific
+catch an error that does not otherwise have a more specific handler
-handler assigned to it. 
+assigned to it.
 
 ##### Error Types
 
-The errors that can be handled are simply all the exception types that
+The errors that can be handled are simply all the exception types that can
-can be thrown by either the DataStax Java Driver for DSE, *or* the
+be thrown by either the DataStax Java Driver for DSE, *or* the nosqlbench
-nosqlbench client itself. This includes errors that indicate a potentially
+client itself. This includes errors that indicate a potentially
 intermittent failure condition. It also includes errors that are more
-permanent in nature, like WriteFailure, which would continue to occur
+permanent in nature, like WriteFailure, which would continue to occur on
-on subsequent retries without some form of intervention. The nosqlbench 
+subsequent retries without some form of intervention. The nosqlbench
 application will also generate some additional exceptions that capture
 common error cases that the Java driver doesn't or shouldn't have a
-special case for, but which may be important for nosqlbench testing purposes.
+special case for, but which may be important for nosqlbench testing
+purposes.
 
 In nosqlbench, all error handlers are specific to a particular kind of
 exception that you would catch in a typical application that uses DSE,
-although you can tell a handler to take care of a whole category
+although you can tell a handler to take care of a whole category of
-of problems as long as you know the right name to use.
+problems as long as you know the right name to use.
 
 ##### Assigned by Java Exception Type
 
@@ -122,9 +125,9 @@ by a closer parent or directly.
 ##### Assigning by Error Group Name
 
 Error types for which you would commonly assign the same handling behavior
-are also grouped in predefined names. If a handler is assigned to one
+are also grouped in predefined names. If a handler is assigned to one of
-of the group names, then the handler is assigned all of the exceptions
+the group names, then the handler is assigned all of the exceptions in the
-in the group individually. For example, 'errors=retryable=stop' 
+group individually. For example, 'errors=retryable=stop'
 
 ### Recognized Exceptions
 
@@ -188,8 +191,8 @@ handled alongside the normal exceptions as explained above.
 2. UnexpectedPaging - The UnexpectedPaging exception is meant to keep users from
    being surprised when there is paging activity in the workload, as this can have
    other implications for tuning and performance. See the details on the
-   **maxpages** parameter, and the *fetch size* parameter in the java driver for
+   **maxpages** parameter, and the *fetch size* parameter in the java
-   details. 
+   driver for details.
 3. Unverified\* Exceptions - For data set verification; These exceptions
    indicate when a cqlverify activity has found rows that differ from what
    was expected.