| Bug #36580 | Exception messages substitute arguments poorly | ||
|---|---|---|---|
| Submitted: | 8 May 2008 0:44 | Modified: | 1 Aug 2008 17:43 |
| Reporter: | Joshua Ganderson | ||
| Status: | Closed | ||
| Category: | Monitoring: Server | Severity: | S3 (Non-critical) |
| Version: | OS: | Any | |
| Assigned to: | Mark Matthews | Target Version: | 2 |
[8 May 2008 23:53]
Joshua Ganderson
revision-id:jganderson@mysql.com-20080508190030-ee3xyoj3karoy0uc revision-id:jganderson@mysql.com-20080508194100-pgk47rsds4uc1nd1 flushed LocaleUtils from CodedException revision-id:jganderson@mysql.com-20080508214232-23ixhyfeegagps1q 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 2: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 20:30]
Marcos Palacios
Verified in bld 2.0.0.6040: Caused a number of exemptions as suggested above. All messages are readable to the user. Bug is not visible for now.
[30 Jul 2008 19:54]
Marcos Palacios
Verified fixed in ver. 2.0.0.6040.
[1 Aug 2008 17: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.
Description: 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.