Report Exception Functional Specification

Author: Petr Blaha

Version: 1.0



Every software product has errors that aren't caught by QA engineers during testing cycle since we can't perform all steps that would be done with IDE. Users aren't willing to log in our bug tracking system, specify all required information and create new bug there. Due this fact many user's errors would stay in Black hole and can impress other users who try our product first time and encounter same error. Therefore, it's good to collect error reports, analyze these data by QA and development.


There is only one following scenario. NetBeans user (Alice) somewhere on the world tries to some obscure functionality in VCS support that wasn't tested by XYZ. She wants to find all commits done by Bob in their code and suddenly the exception is thrown. Of course, this isn't a problem of her since she didn't make anything wrong but our product jumped in some not well handled condition. This is a definitely bug when user faces exception dialog, right? However, Alice is active NetBeans community memeber and she wants to improve our tool. Alice clicks to Report Problem button that is in error dialog. Then, she verifies all data that are gathered from her system and sends the report to server. The report is processed (description of the process is below) and she can see the short info about status of the exception in web browser next.


I have several meetings with my colleagues from different team about reporting exceptions directly from IDE. See a whiteboard with comments after our hour discussion. They pronounced following requirements for this system: File:ReportExceptionSpec/exception reporter process ReportExceptionSpec.JPG

  • Don't store the exception reports directly to Issuezilla (IZ) and use different external database. This database is intended for bug's pre processing of new reports. Of course, with this approach we should solve how to migrate these reports in our bug tracking system. With this step the reporting of exceptions lost sense. The bug's pre-processing and migration would be done by QA team. They can track new reports and migrate reports to bug tracking system manually. However, I met QE folks and they stated next requirement.
  • The system shouldn't overload QA team. They pointed out new system where they should monitor bugs can reduce their productivity. Therefore, the data in external database are preprocessed automatically (assignment component/subcomponent, identifying duplicates) then the new issue is created in IZ automatically.
  • Require IZ login for reporting exceptions. In many cases additional informations are requested for fixing bugs and also user can be interested in status of their bugs. Registering on isn't big deal since only e-mail and login name is required.
  • Decouple importing reports to IZ and storing new reports in external database. In some cases should be possible to manually disable importing reports in IZ. This action should be possible without any web module compilation.
  • Publish daily/weekly statistics about reported exceptions like number of new exceptions, nr. of duplicates, nr. of reports from unique user, ...

The architecture and processes that satisfy above requirements are described in next section.

Overview and flow diagram

System from user's point of view

Let's start to describe reporting exception from user's point of view.

  • In the exception dialog is Report Problem button. When user clicks on the button following dialog is displayed.
| Report Problem                                                              X |
|  We have created an error report. We will treat this report confidental.      |
|  No personal data will be transmitted other than you provide to us.           |
|                                                                               |
|  Since you will be informed about the state of this problem,                  |
|  you need to be a registered user. If you're not registered,                  |
|  you can register here.                                                       |         
|                                                                               |
|  Your username: |'''_''''''_''''''_''''''_''''''_''''''_''''''_''''''_''''''_'''|  |
| password:      |'''_''''''_''''''_''''''_''''''_''''''_''''''_''''''_''''''_'''|  |
|                                                                               |
|  ---------------------------------------------------------------------------  |
|                                                                               |
|  Describe what you were doing when the exception occured:                     |
|   '''_''''''_''''''_''''''_''''''_''''''_''''''_''''''_''''''_''''''_''''''_''''''_''''''_''''''_'''___   |
|  |                                                                         |  |
|  |                                                                         |  |
|  |                                                                         |  |
|  |                                                                         |  |
|  |                                                                         |  |
|  |                                                                         |  |
|  |                                                                         |  |
|  |                                                                         |  |
|  |'''_''''''_''''''_''''''_''''''_''''''_''''''_''''''_''''''_''''''_''''''_''''''_''''''_''''''_'''___|  |
|  To see what data report contains, click View Data button.                    |
|  [[[_V_iewData | [_V_iew Data]]]                             [[[_S_ubmitData | [_S_ubmit Data]]]   [[_C_ancel] | 
  • User is asked for IZ login name and password (mandatory fields). He can clicks to here and the web browser with registration page is opened.
  • User can specify what he was doing when the exception was thrown (optional).
  • The View data button open the dialog where the user can check all data that are transmitted
  • Login name should be verified before report is transmitted.
  • The login/password should be store in user directory.
  • The IZ login should be checked when the user/password is entered. IMPL. NOTE: This requires web services that exposes checkIZlogin and the method is invoked when user/password text field lost focus. However, there are issue when the IZ is down. Should we allow to report exception as guest? The submit button is disabled till user is verified via checkIZlogin Web Service.
  • Allow to change name and password in Tools -> Options -> Miscellaneous -> Report Exception
  • When the login/password was specified then the login name text field should be read-only and password disabled.
  • The report is sent to server when user clicks on Submit Data button.
  • Next, a web browser is opened with page with thank to reporting error.

Processing a new exception report

File:ReportExceptionSpec/reportFlow1 ReportExceptionSpec.png IMPL. NOTE:

  • In the future we can switch to new bug tracking system and this would be assumed in implementation.
  • The criteria for creation new IZ issue would be flexible and can be changed. For instance, we can import also all OOME automatically to IZ in the future.

Assign component/subcomponent

See here.

Duplicate algorithm

The algorithm is described here.

Not logged in. Log in, Register

By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo