AutomaticBugReporter

TableOfContents([2])

Proposal

Automatic error detecting and reporting has become common practice in desktop application and web-based application. The bugs found in the filed may be those that would never be caught during testing. With an automatic bug report system, to file a bug report is just a click on a button on a dialog, therefore bug-reports from various kinds of users become possible, including those non-technical and won’t bother to login to bug tracker and file a detailed report.

Cytoscape should also have such automatic bug reporting system, which would potentially increase more feedbacks from Cytoscape users and help developers to fix the bugs. This RFC describes how to build an automatic bug reporter for Cytoscape.

Use Cases

1. GUI mode

Scenario: A user is using Cytoscape for a while and suddenly Cytoscape runs into a problem. An exception is caught and the exception is classified as a bug. A dialog box pops up and asks user if he/she wants to report the error to Cytoscape. If user says “Yes”, information about the bug will be sent to Cytoscape bug tracker.

. attachment:CyAutoBugReportDialog.JPG

. attachment:CyAutoBugContents.JPG

2. Headless mode

Cytoscape is running in headless mode and the mode is “interactive”, not “server”. When an exception is caught and the exception is classified as a bug, a message on the console will tell the user what happened and ask the user if he/she wants to report the error to Cytoscape. If user says “Yes”, information about the bug will be sent to Cytoscape bug tracker.

3. Do not report any bug

In the case that a user decides not to report any error, the user has the option to set the property value “automaticErrorReport” (true, by default) to false and Cytoscape will remember the decision.

Collecting data from Cytoscape user

When Cytoscape crashes or exception thrown, the following information from user should be collected and submitted directly to Cytoscape bug tracker, Mantis

• Cytoscape version
• OS version and other system info

• ErrorCode (or Error Number) – depend on the bug category, API/CORE/GUI/PLUGIN/VISUALSTYLE/OTHER

• The class and line number in the code where the crash occurred
• The error message (full stack trace)
• User’s Description
• User email address (Optional)

ErrorCode will be used for bug classification purpose and make it easy for bug management in Mantis. We encourage user to give a description about what they did before Cytoscape runs into the problem. This will be very helpful for developer to reproduce the bug. User email address is optional. Many users may not give us their email address at all. However, in case the same bug is reported multiple times, and developer has questions about it, we may contact user if he/she did give us email address

Format of bug report and identification of duplicated bugs

The subject (summary) of bug report should have the format like this, ErrorCode:ClassName:Method:LineNumber:OS:OSVersion

This format is needed to determine if a bug has already been reported.

If a bug has already been reported (with the same subject), the report should be appended to the existing one, rather than open a new one.

Automatic bug reporter will be part of CyLogger

Since Cytoscape 2.6.1, Cytoscape has its own Logger, CyLogger, which catches all kinds of error messages and present them to the users or developers. CyLogger may be extended to include the automatic error reporter. CyLogger can catch different log messages, including warning, info. However, only Error or Fatal should be reported as Bugs. Any exception thrown in Cytoscape should be caught. If the error will go through the automatic reporting system, appropriate ErrorCode should be assigned based on the nature of the error.

Implementation Plan

The implementation of the automatic bug reporter includes two parts, client side (Cytosape) and server side (Mantis). The client would be responsible for data collecting and submission only and the server for data processing. If a task can be done in either client or server side, we prefer to put it on server side. This is important for easy maintenance in the future.

Cytoscape (client side)

Two Java classes in cytoscape.logger package are needed for automatic bug reporter. 1. ErrorCode.java Definition of various Error codes 2. SubmitErrorReport.java If GUI mode, generate dialogs and submit the data to Cytoscape bug tracker if user says “YES”. If headless mode, prompt for user input and submit the data to Cytoscape bug tracker if user says “YES”.

The automatic error reporter will be triggered by exceptions caught at running time. The following is a snippet of code to show how the automatic bug reporter is triggered.

try {

• //some code

} catch exception (Exception e){

• logger.SubmitErrorReport(ErrorCode.XXXX, e);

}

Mantis (Server side) 1. Virtual person: Automatic bug reporter should have its own user name “Automatic bug reporter” in Mantis -- a virtual person, instead of a real developer.

2. New PHP script (bug_report_auto.php): the new Mantis PHP script will be triggered by “SubmitErrorReport” of Cylogger. This PHP script will (1) check the summary (subject line of the bug report) of the Bug report (2) if this is a new bug, create a new Bug in Mantis, if this is a duplicated bug, append the new report to existing one.

Project Timeline

Provide a timeline for implementation. Insert a graphic if you can. Try this free online tool for making project timelines -> [http://www.helpuplan.com/index.asp Help-u-Plan] (create a new chart; modify; right-click to save gif; then attach to this page)

Tasks and Milestones

Outline the major milestones and tasks involved in implementation.

1. Milestone 1: …

   1. Task 1: ...
   2. Task 2: ...

2. Milestone 2: …

Project Dependencies

Outline and projects that depend on this project, link to relevant RFC's and note at what point dependent projects could be started.

Related RFCs

Link to other related RFCs

Issues

List any issues, conflict, or dependencies raised by this proposal

Comments

• Add comment here…

How to Comment

Edit the page and add your comments under the provided header. By adding your ideas to the Wiki directly, we can more easily organize everyone's ideas, and keep clear records. Be sure to include today's date and your name for each comment. Try to keep your comments as concrete and constructive as possible. For example, if you find a part of the RFC makes no sense, please say so, but don't stop there. Take the extra step and propose alternatives.