Re: [Spacewalk-devel] Exceptions, i18n and error messages
On Wednesday 07 of March 2012 13:43:53 Duncan Mac-Vicar P. wrote: > I have been working on NewChannelHelper, CreateChannelCommand, > ChannelSoftwareHandler and EditChannelAction. > > Right now NewChannelHelper does some verifying and implements cloning, > while new channel creation is implemented in CreateChannelCommand. > > Basic validation is in two places, > > CreateChannelCommand validates and throws (translated) exceptions. > > NewChannelHelper implements the logic (but only answers true or false) > and then the clone operation in the same class creates an untranslated > InvalidChannelParameter exception. > > This makes sense, as NewChannelHelper::clone is used in > ChannelSoftwareHandler (xmlrpc) for the clonning, so an untranslated > error is ok (despite the duplication). > > When I refactored the validation in one place, I kept the ones from > CreateChannelCommand, which are translated. I remember Tomas Lestach > mentioning in irc that it is important that these xmlrpc exceptions are > untranslated. Not really. I said, that we usually do not translate API exceptions. That means I know a few of them being translated, but there's not a strict requirement to have them localized. > Everything fine, however then I realized > ChannelSoftwareHandler uses CreateChannelCommand for creating channels, > and therefore it receives translated exceptions. > > EditChannelAction catches the exceptions and based on the reason > constructs ActionMessages no matter if the exception was already > translated or not. If I could use the translated ones, I could remove > the switch per-reason and just construct an ActionMessage directly from > the Exception. > > Any guidance here? Ideal case would be to work just with the "cause/description identified" and localize it just before the handover to the user (or not localize it - let's say according to a predefined option for API exceptions). However I know the most of our code is far away of it. Regards, Tomas -- Tomas Lestach RHN Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] Exceptions, i18n and error messages
I have been working on NewChannelHelper, CreateChannelCommand, ChannelSoftwareHandler and EditChannelAction. Right now NewChannelHelper does some verifying and implements cloning, while new channel creation is implemented in CreateChannelCommand. Basic validation is in two places, CreateChannelCommand validates and throws (translated) exceptions. NewChannelHelper implements the logic (but only answers true or false) and then the clone operation in the same class creates an untranslated InvalidChannelParameter exception. This makes sense, as NewChannelHelper::clone is used in ChannelSoftwareHandler (xmlrpc) for the clonning, so an untranslated error is ok (despite the duplication). When I refactored the validation in one place, I kept the ones from CreateChannelCommand, which are translated. I remember Tomas Lestach mentioning in irc that it is important that these xmlrpc exceptions are untranslated. Everything fine, however then I realized ChannelSoftwareHandler uses CreateChannelCommand for creating channels, and therefore it receives translated exceptions. EditChannelAction catches the exceptions and based on the reason constructs ActionMessages no matter if the exception was already translated or not. If I could use the translated ones, I could remove the switch per-reason and just construct an ActionMessage directly from the Exception. Any guidance here? -- Duncan Mac-Vicar P. - http://www.suse.com/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Maxfeldstraße 5, 90409 Nürnberg, Germany ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
