Oracle Visual Builder: Applications That Outlive Their First Release · Module 10 · Validation and error handling
Logging, for somebody who is not there
Lesson 106 of 176 · 3 min
What to record when it goes wrong FOR A USER YOU CANNOT WATCH, and WHAT MUST NEVER BE RECORDED. A failure in a browser you have no access to leaves no trace unless you left one, and the report you receive will be one sentence with no timestamp in it. WHAT TO RECORD IS WHAT WOULD LET YOU REPRODUCE IT. Which operation, when, what the service returned, and enough about the context to find the record — the identifier of the thing being saved, the page, the browser. "A save failed" is not a log entry; "the save of order 4471 was refused at 14:02 with this validation message" is one. AND RECORD SUCCESS AS WELL AS FAILURE FOR ANYTHING THAT MATTERS. Half of these investigations are "did it save at all", and a log that only holds failures cannot distinguish "it worked" from "the failure was not logged". WHAT…
The full lesson is part of the course
The video, the complete written lesson and the module quiz are included in Oracle Visual Builder: Applications That Outlive Their First Release, with a certificate on completion and a fourteen-day refund window.
In this module: Module 10 · Validation and error handling
- 1Where validation can live
- 2Client-side validation is a courtesyFree preview
- 3Field-level and form-level
- 4Messages a user can act on
- 5Reading an error from a service
- 6Errors in Arabic
- 7Failing without losing the work
- 8Logging, for somebody who is not there
- 9What breaks: three validation failures
