JXErrorDialog

API For external review (30 October 2006)

• JXErrorPane
• ErrorReporter
• ErrorInfo

Notes/API for Internal Review 25 July 2006

Reference API as HTML:

• EmailErrorReporter
• ErrorReporter
• IncidentInfo
• JXErrorDialog
• LogErrorReporter

Feedback from Internal Review (25 July 2006):

• JXErrorDialog must be as easy to use as System.out.println
• IncidentInfo should contain as much state as is reasonable
  • System properties
  • Developer specified application state
  • Whether the error occured on the EDT
  • system time
• basicErrorMessage and detailedErrorMessage must both support some template syntax to facilitate easier creation of error messages
  • probably support something like ${System.currentTimeMillis}, ${System.os.version}, etc.
• MessageFormat or something for the details portion
• Need to spec what "simple" HTML is (HTML 3.2 -- essentially anything that JEditorPane supports)
• Remove the "Because" -> don't do that at the beginning of a sentence "Before showing the JXErrorDialog you may..."
• JXErrorDialog may not work because you can't use it in an internal frame. Also, you can't do any LAF stuff on it if it isn't a JComponent
  • Rename it JXErrorPanel/JXErrorPane, use showDialog etc
• Need to spec what a valid report action must contain (such as the name, smallIcon, etc) since that information is used to construct the "report" button
• IncidentInfo needs to explain what "simple" HTML is too
• By default, when JXErrorDialog is shown logging should occur
• By default, you always want to have the report button showing (not so fast: maybe you want to report the error automatically but not have the button showing)
• Consider making "url", "email", "logger" etc all part of JXErrorDialog because it may be a pain to create the actual ErrorReporter all the time
• In the "show" methods, make sure you're on the EDT
• In the list of properties/state of the error, track the EDT if possible
• How to handle exiting the application on fatal errors? Need to attach listeners to track a closing window? Or add a button? FatalAction? CloseAction? This is an open issue
• Let everything be null in IncidentInfo
• Consider automatically sending fatal error reports instead of giving them a report button

Notes/API for Internal Review 14 August 2006

Reference API as HTML:

• CompoundErrorReporter
• EmailErrorReporter
• ErrorInfo
• ErrorLevel
• ErrorReporter
• JXErrorPane
• LogErrorReporter

And a couple pictures for reference:

• JXErrorPane in Metal
• JXErrorPane on Mac

Feedback from Internal Review (25 July 2006):

JXErrorPane:

• Need to document the nature of the showXXX methods in the class level documentation since they all conform to a specific pattern
• Need to document that the showXXX methods block (modal)
  • Ensure use of invokeAndWait() in showXXX methods if not on EDT
• Use these 4 methods (with similar methods for frame and internal frame), and remove the others
  • showDialog(Throwable)
  • showDialog(JComponent owner, ErrorInfo)
  • showDialog(JComponent owner, JXErrorPane)
  • createDialog(JComponent owner, JXErrorPane)
• Remove setWarningIcon, setErrorIcon. Replace with setIcon
• Document which UI Default keys are used in JXErrorPane & plaf classes
• Remove setDefaultXXX static methods (problems arise when used in connection with multiple apps in one JVM)
• Remove report-action because it introduces a crazy linkage with error reporter (we didn't all agree this was the best course of action)
  • This suggests that customizing text/icon of the "report" button is not support
  • An alternative is to remove ErrorReporter, and let the report action do the job of reporting (or whatever it wants to do). Could replace EmailErrorReporter with EmailReportAction, etc
• Nuke DefaultErrorReporter -- nobody needs it to be public (and if either Report Action or ErrorReporter is tossed, then it isn't necessary)
• Merge the fatal action into the error reporter (this is not agreed on either!)

ErrorInfo:

• Document the default value and add @see for each of the properties (where appropriate)
• Document the tie between app state and substituteVariables
• Move substituteVariables to a Utils method in org.jdesktop.swingx.utils and rename to replaceVariables
• Remove other constructors -- only keep the main one. Constructors can always be added and it isn't clear which we really want

EmailErrorReporter:

• setToAddresses(String addresses) <-- takes input like "some.body@mycompany.com, other.body@mycompany.com"
• remove cc and bcc addresses. Are these really necessary?
• no decision was made about keeping the attachments API. Seems reasonable for attaching a screenshot to the error report, but that might constitute a breach in privacy