Taxonomy of Errors
Here is a breakdown of different types of errors and names for them. Use these terms when reporting bugs, and make sure that you provide the logs with the bug report.
• Crash — The client application has unexpectedly stopped executing. There is no longer a process running for the application. If a process is running, the application did not crash. Typically, a crash is the worse case. An example of a crash is a seg fault. If this fault appears in your logs, report that a crash has occurred and make sure that you provide the logs to PTC Support.
• Locked, deadlocked, or hung — The client application still has a process, but it is no longer responding. Another possibility is that the application responds to some input, but not all input. In this case, possibly one or more threads in the application, but not all, are blocked.
• Bug — The application is not behaving as expected, but it continues to execute. This is the standard bug case. Usually, there is no error message, since the application believes it is behaving correctly.
• Reporting an error: The logs show an unexpected error message. The application is still executing and responsive, but most likely it is not behaving correctly. To troubleshoot such an error, shut the application down, change the log level to TRACE, and run it again. If the error occurs again, you will have a verbose log that PTC Support can use to detect the problem. Always include stack traces in bug reports. On the ThingWorx platform, be sure to check the file, ErrorLog.log. Sometimes an error in the log of the application will have a corresponding message in the error log for the platform that includes a stack trace.
• Not behaving as hoped: The user expected the application to behave one way, but it is behaving differently. There might be a workaround, or the expected behavior might require a feature request.