|Anonymous | Login | Signup for a new account||2020-10-31 18:43 UTC|
|Main | My View | View Issues | Roadmap | Repositories|
|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|
|Priority||normal||Severity||minor||Reproducibility||have not tried|
|Target Version||0.9.24||Fixed in Version|
|Summary||0000423: Improve Error Handling Flow/Semantics|
"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.
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.
|Tags||No tags attached.|
|Due to your comms design Everything is asynchronous. Correction, mtx wont loop on error only timeout. You'd know this if you used it more. Error wimdow is pending however i am holding back due to the flames i get over any popups no matter how dismissable i make them...|
|You're right, let me test what it does and whether you let me do invalid things or not. One moment please.|
For a start! :-)
This can stay open until you clarify that either your earlier statement is wrong, and it doesn't do what you said in a loop, or the behaviour is fixed.
|linked to issue is closed, hence it appears this should be closed|
|Jeff, any chance of testing this? If you need clarification, just ask. If you don't have time, send it back my way and I'll have a play at some point. Thanks.|
|Copyright © 2000 - 2011 MantisBT Group|