Bug #36580 Exception messages substitute arguments poorly
Submitted: 7 May 2008 22:44 Modified: 1 Aug 2008 15:43
Reporter: Joshua Ganderson Email Updates:
Status: Closed Impact on me:
Category:MySQL Enterprise Monitor: Server Severity:S3 (Non-critical)
Version: OS:Any
Assigned to: Mark Matthews CPU Architecture:Any

[7 May 2008 22:44] Joshua Ganderson
In the cases where we pass through exceptions to the UI, the substituted arguments in the message are not for human consumption. For instance, an unsupported data collection item when trying to schedule a rule may look like:

The server "{mysql}.{server}.{a585a76c-bae7-4642-ae77-817cf42ef32b}" does not support item(s) "mysql.server.Last_Error" required by monitor "cd36f2bf-8cf2-4de6-b03e-61e8037e68df

What's happening is that the toString() is being called on each of the objects passed into the exception as arguments. The return of the toString() for each object is for developer consumption and has little meaning to the user.

How to repeat:
Schedule all the replication rules against a server that's not in a replication group.

Suggested fix:
We have a few options here.

1. Change toString() to be nice display values (makes the dev process a little more difficult and it's easy to forget to make a nice toString() for all objects)

2. Create a ToNice interface that our exceptions implement. CodedException could either store the arguments as the toNice() of the passed in arguments or it could have a getParameters() that returns a collection of the toNice() on the arguments (if we needed to preserve the objects for some reason).

Also, I'd like to get rid of the localization that lives in CodedException. The UI should be responsible for generating the message from the exception using e.getCode() and e.getParameters(). Processes like email notifications will have access to LocaleUtils and be able to do the same. Note that I'd like whatever happens here play nice with ErrorCodeMapping. I'm currently thinking getCode() should return a key like "schedule.error.unsupportedItem" which is mapped in ErrorCodeMapping.

Not only would this centralize error handling, it would remove the circular dependency issue we have with our exceptions and the LocaleUtils.
[8 May 2008 21:53] Joshua Ganderson
flushed LocaleUtils from CodedException

special cased Server and Rule display when they are arguments in a translation call

Pending work is to identify other items that require special casing
[9 May 2008 0:00] Joshua Ganderson
Since it's uncommon that we surface errors from the server level and I resolved the case talked about in the body of this bug. I'm marking this as qa testing. However, if QA finds or knows of any other cases like this, pass the bug back and I'll take care of it.
[22 May 2008 18:30] Marcos Palacios
Verified in bld Caused a number of exemptions as suggested above. All messages are readable to the user. Bug is not visible for now.
[30 Jul 2008 17:54] Marcos Palacios
Verified fixed in ver.
[1 Aug 2008 15:43] Tony Bedford
An entry has been added to the 2.0 changelog:

In the case where exceptions were passed through to the User Interface, the substituted arguments in the message contained developer-only information.