FreeEMS Issues - Tunix | |||||
View Issue Details | |||||
ID | Project | Category | View Status | Date Submitted | Last Update |
0000423 | Tunix | FreeEMS Plugin | public | 2011-11-26 00:28 | 2012-04-01 17:10 |
Reporter | Fred | ||||
Assigned To | ToxicGumbo | ||||
Priority | normal | Severity | minor | Reproducibility | have not tried |
Status | assigned | Resolution | fixed | ||
Platform | All | OS | All | OS Version | All |
Product Version | 0.9.24-SNAPSHOT | ||||
Target Version | 0.9.24 | Fixed in Version | |||
FirmwareVersion | |||||
Summary | 0000423: Improve Error Handling Flow/Semantics | ||||
Description | Quote: "If a location ID requires a full write, right now, mtx has no way to know that it does, thus mtx will get stuck in a loop right now, as if it tries a partial write to a full write page, and you return and error, megatunix doesn't know how to handle that and will just keep retrying over and over and over again." Irrespective of the full/partial write issue, which we'll discuss and solve another day, this flow is a little broken. It's necessary to distinguish between different types of failures to perform the action inside the application. There are at least two failure modes, possibly more: - Packet timeout - Error response The former should resend if the packet is one that requires guaranteed delivery (not a datalog request). The latter should simply give up and preset the error to the user to deal with, either by correcting their actions based on the message or alerting you to the incompatibility. The fact that you get an error response back implies that something was wrong with what you sent, either by the application's design, or by the users action. Unless you explicitly handle each error code with custom actions you can't reasonably expect to do anything other than show the user the error and move on. Certainly looping when the device is TELLING you that something is wrong is not a wise behaviour choice. The only really correct thing to do in all cases when receiving a specific error code back from the firmware is to display that code, with or without a message, to the user in an obvious way. Synchronous errors should be sufficiently rare to always pop up a message for, or at least bring an error list window such as the one visible in the picture below to the front of the screen to grab attention. http://www.ectune.com/Portals/0/screenshot2.png [^] This is strongly related to issue 0000251 in which I didn't know the full extent of the problem. Asynchronous errors will need a different mechanism as there is the potential for those to come in a flood. | ||||
Steps To Reproduce | |||||
Additional Information | |||||
Tags | No tags attached. | ||||
Relationships | |||||
Attached Files |
Notes | |||||
|
|||||
|
|
||||
|
|||||
|
|
||||
|
|||||
|
|
||||
|
|||||
|
|
||||
|
|||||
|
|