Issie
ExceptionReport Module
What the user sees of everything that has gone wrong this session. Two things use this. The Bug Reports tab shows the panel below, so that somebody who has been asked for details can get them without opening dev tools - which the checklist beside it asks them to do, and which most people reporting a bug will not manage. And the renderer's exception boundary shows `crashPage` when the view itself throws, which is the one case where the Info window cannot be opened to read the panel. **The text is the deliverable.** Everything here exists to get `Log.problemReport ()` into a forum post or an email, so the panel is a block of text and a button that copies it, and not a table of exceptions with columns. The same text is on `window.issieLog.report()`, so a developer sitting at the machine reads exactly what a user would have sent.
Nested modules
| Modules | Description |
Functions and values
| Function or value | Description |
|
What the Copy button puts on the clipboard: the same, and the questions as a form. **The questions travel with the report because that is where they get answered.** A checklist read on one screen and typed into an email on another is a checklist half of which is forgotten; one that arrives already in the email, above the evidence, is answered in place. They come from `AppMessages.Info.bugReportQuestions`, the same list the tab renders.
|
|
What is drawn when drawing anything else threw. Deliberately does not try to be the application: there is no dispatch it can trust, because whatever the view choked on is still in the model, and a button that dispatches would run the same render again. What it can do is say what happened, show it, and offer the clipboard - so that a session which is over anyway still produces a usable bug report.
|
|
The Bug Reports tab's panel: what has gone wrong, foldable so that it does not bury the checklist above it, and a button that puts the lot on the clipboard. `details` rather than a model field, because whether a user has this open is not something the application needs to know or to remember - and holding it in the model would mean a message, an update case and a render of the whole application for a disclosure triangle.
|
|
The popup a debug build puts up when anything is logged as an error, or when an exception reaches the boundary. **This exists because a developer does not read the console.** Every error already reached the buffer and the Bug Reports tab before this was written, and that was enough for a user being asked for a report and no use at all to the person who could have fixed it: it says nothing at the moment the mistake is made, which is the only moment at which anybody remembers what they just did. So a debug build interrupts, and a release build does not. The tickbox is the other half. Interrupting is only tolerable if it can be stopped, and an error that repeats - a failing sidecar, a handler that throws on every drag - would otherwise make the app unusable in exactly the build being used to debug it.
|
|