Uploaded image for project: 'PUBLIC - Liferay Portal Community Edition'
  1. PUBLIC - Liferay Portal Community Edition
  2. LPS-37301

Refactoring exceptions, exception generation and processing

    Details

    • Type: Feature Request
    • Status: Open
    • Priority: Minor
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: Core Infrastructure
    • Labels:
      None

      Description

      Hi everybody,

      I could see recently some pattern in exception generation and processing and I would like to discuss it with you all.
      We have several exceptions (i.e. AssetTagException, AssetCategoryException or LayoutTypeException among others) that have some final constants inside.
      These constants seem to be used as a custom subtyping system for the exceptions. I propose we should use subtypes for this (creating new child classes of the exception) thus leveraging the language. I can see no real benefit of not doing so.

      On the other hand it seems to me that many of the exceptions are not recording the state that produced them. As an example I would expect an INVALID_CHARACTER exception to capture the character that is invalid. This is best done subclassing types.
      This would help as well with exception localization. Right now we are forced to localize the exceptions everywhere they are catched. This, along the fact that many times we don't have the conditions that produced the exception, leads to duplicated exception processing and inaccurate error messages.
      I think we could create localized exceptions (java Throwable already has a getLocalizedMessage method for this purpose) and allow the subclasses to generate the localized messages when fed with the proper locale. I believe this would allow us to create some general logic to deal with exceptions that could be reused all portal wide. Should this general behaviour be overriden we could do so using the standard mechanisms of exception catching and wrapping, for example if we have at some point some more accurate information for the user we can wrap up the original exception in other with more information and propagate it upwards.

      I know this is kind of a long post, but I would love to know your thoughts on these.

      Bests!

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                support-lep@liferay.com SE Support
                Reporter:
                carlos.sierra Carlos Sierra
              • Votes:
                1 Vote for this issue
                Watchers:
                2 Start watching this issue

                Dates

                • Created:
                  Updated:

                  Packages

                  Version Package