Ticket #320 (closed enhancement: fixed)
Logging improvements
| Reported by: | Joel | Owned by: | Joel |
|---|---|---|---|
| Priority: | major | Milestone: | Eraser 6.1/6.2 |
| Component: | Core | Version: | |
| Keywords: | Cc: | ||
| Processor Architecture: | Blocked By: | #300 | |
| Blocking: | #275 | Operating System: |
Description (last modified by Joel) (diff)
The logger is currently very involved when doing logging -- we need to instantiate new LogEntry structs, we need to initiate sessions etc. It's also very fickle about the validity of sessions. The Logging should be able to tolerate errors and should be more flexible.
The Last Sesssion timestamp is not reset after a session is completed; new messages go to the wrong session.- The log should also include the statistics and result of an erase task.
Differentiate between "Completed with Errors" vs "Aborted with Errors" etc etc.- What qualifies as errors?
What do errors imply? Do Errors mean that the target didn't complete? Do fatal errors mean that the entire task didn't complete?
Blocking
| Id | Summary | Milestone |
|---|---|---|
| #320 | └ Logging improvements | Eraser 6.1/6.2 |
| #275 | └ Code Review | Eraser 6.1/6.2 |
| #262 | └ Localise the Util.Native and Util libraries | Eraser 6.1/6.2 |
Blocked by
| Id | Summary | Milestone |
|---|---|---|
| #320 | └ Logging improvements | Eraser 6.1/6.2 |
| #300 | └ Tasks - Information log entries for start / end | Eraser 6.1/6.2 |
Change History
comment:9 Changed 3 years ago by Joel
- Description modified (diff)
These really trigger conditions which can't be recovered simply by returning.
comment:10 Changed 3 years ago by Joel
- Description modified (diff)
Yeah, these are already handled -- Not Completed vs. Completed with Errors.
comment:11 Changed 3 years ago by Joel
- Status changed from accepted to closed
- Resolution set to fixed
The rest of this task is actually a non-issue. I'll close this.
Note: See
TracTickets for help on using
tickets.
