-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Wed, 25 Mar 2009 22:45:46 -0400
Jesus Rodriguez <[email protected]> wrote:
> This is more of a note to self, but I'd figured I'd share with
> everyone. We need to revisit our exception classes, the api has a
> very rich set of exceptions that can be useful by other parts of the
> code.
>
> Most folks don't want to use them because they live in an xmlrpc
> package, and we could probably move them to a more common location.
> Another reason is not all of the api exceptions are localized (usually
> the older ones).
>
> Another thing I noticed was that the exceptions that are localized
> none of them use the FaultExceptions constructor which accepts the
> localized parameters:
>
> public FaultException(int error, String lbl, String messageId,
> Object [] args)
> { super(LocalizationService.getInstance().getMessage(messageId,
> args)); this.errorCode = error; this.label = lbl;
> }
>
> We seem to do it the hardway :)
>
> ...
> super(1062, "Invalid Arch" , LocalizationService.getInstance().
> getMessage("api.system.invalidarch", new Object [] {arch}));
>
> This could've been easily written as:
>
> super(1062, "Invalid Arch", "api.system.invalidarch", new Object []
> {arch}));
>
> Honestly, I would do away with the messageid altogether and use
> the exception label as the messageid. So the ctor would change to:
>
> super(1062, "Invalid Arch", new Object [] {arch}));
>
> And in FaultException (top example) it would change to this:
>
> public FaultException(int error, String lbl, Object [] args) {
> super(LocalizationService.getInstance().getMessage(lbl, args));
> this.errorCode = error;
> this.label = lbl;
> }
>
> Oh back to the organization, I think we should move the Exceptions to
> com.redhat.rhn.common.errors. except for maybe the truly specific
> errors which could remain in the xmlrpc package.
>
> Thoughts?
>
Are we talking about about localizing and defining error codes
for exceptions throughout the application here?
I always considered these relatively API specific, and in general an
Exception isn't something I expect to bubble up to the UI and need
localization. Normally we just see Internal Server Exception in the UI
right? And then the admin consults the logs to find the actual
exception details. To me this doesn't really need localization, and I
would prefer to avoid the overheard.
I'm not real keen on getting into fine grained exceptions for
everything that could go wrong either, I feel this is required in the
API to some extent as users writing scripts on the other end need
them, but elsewhere I only like to do this if there's a specific reason,
i.e. I need to detect that a specific problem happened and handle it
somewhere else. Otherwise I prefer to avoid the class bloat and re-use
generic exceptions.
If however we are thinking about doing localization + error codes all
over, we probably want to come up with a better way for defining the
codes. It's manual today and not great, probably need some tools for
finding free codes, defining the subject matter ranges, and detecting
dupes.
Cheers,
Devan
- --
Devan Goodwin <[email protected]>
Software Engineer Spacewalk / RHN Satellite
Halifax, Canada 650.567.9039x79267
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
iEYEARECAAYFAknLnm0ACgkQAyHWaPV9my5T8ACgwz/N2VXLTQbfzXes7Pqsj3sr
x1IAn3VgwT45ZOH8K/U11IuxsvI+T7T5
=Tmtm
-----END PGP SIGNATURE-----
_______________________________________________
Spacewalk-devel mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/spacewalk-devel
