Some Convio form errors not documented for API use?

Serge Tkachov

I realize that this is not a quick fix that support can do or recommend, rather a design issue or flaw. There is no reason that some errors are published/documented and others are not.

To illustrate my point better.

Microsoft documents every exception for each class that it publishes for programmers to use (and if they missed something it is recognized as a bug by the programming community), otherwise a programmer would not check for that exception in his code and end up with an uncatchable exception of his own and his program would crash.

So at the very least all possible errors that Convio modules can produce and return to the programmer should be documented along with the module.

My second point

If the error message is generic, i.e. "Email is required", and there is more than one email field on the form/page, there needs to be a way to connect this error message to the correct field, otherwise end user may be confused as to which field this error is referred to. Note: there are many generic error messages from ghost form like: "String is too long" <- not exact quote, that have to be mapped to their specific field.

So if all error messages were available for a programmer to edit, we could do the mapping ourselves by setting an id in front of the error message and then use it in the error catching routine. This is not a matter of looking for a particular error string and customizing it for the user in a more friendly way, but rather having control of the source of error message. (and if your error string should change, it will not match our conditional anymore).

So far I have found several error messages that are not documented, by sheer testing for various conditions, but I cannot guarantee that I tested for all the conditions, so there might be some error messages that would fall through. I will still display them, but in a non-standard way, as an exception and we want to avoid such "surprises".

Undocumented error messages found to date by me: (if anyone found others, please post)

For Credit Card fields:

1. Credit Card number is null/empty

2. Credit card expiration...

For Installment payment:

1. Duration...

2. Frequency...

For eCard Recipients

1. Please enter a valid email address

2. Please enter a valid list of email addresses separated by commas or semi-colons or entered on separate lines.

For Donor Email

1. The email address is invalid

Thanks,

-serge