I would assume you're right that very few are transient. At least with Mikes approach, you can log the error, notify the user and continue working from a clean state (but I assume if the user does the same thing again the error would happen again - that is, they can continue doing "other" things).
On Fri, 15 May 2015 16:03 Colin Yates <[email protected]> wrote: > Data for the win. > > I remember in the olden days when AOP reared its head and people were > talking about retrying updates against stale data/exceptions. I was > always/still am a bit cynical because I just don't see that many > exceptions where the exception is transient and the second attempt > would work. > > I would be very interested to know how many UHEs are genuinely > 'transient', in that they don't happen again when the user tries to do > the same thing - do you have any metrics? > > On 15 May 2015 at 15:56, Mike Thompson <[email protected]> wrote: > > On Saturday, May 16, 2015 at 12:36:02 AM UTC+10, Colin Yates wrote: > >> For me, I can't use the 'snapshot app-db and discard' as the app-db is > >> synchronised with the server periodically. As you mention, I have a > >> number of roots in my app, one for 'ui' entries and one for 'views' > >> which are populated by the server, even if I want to discard the 'ui' > >> root I really don't want to discard the 'views'. > >> > >> I avoid local state as well simply because the benefit of being able > >> to capture the whole app-db and attach it to a bug report is awesome. > > > > > > We've now hooked window.onerror and in production, and when there's an > unhandled exception, we automatically do an "undo", to take the user back > to the previous known sane state. It works a treat. (Not that we get many > UHE, you understand :-)) > > > > It means the user still has a working program (with error message), and > hasn't lost anything because of the problem. > > > > AND, as you say, we serialise the app-db and the event which caused the > UHE, to form the perfect, reproducible bug report. (We also have a log of > all previous events too ... because they are pure data). > > > > It brings a tear to my eye its so damn beautiful. > > > > That all comes almost for free because the data is all in the one place > and because events are pure data to boot. > > > > > > -- > > Mike > > > > -- > > Note that posts from new members are moderated - please be patient with > your first post. > > --- > > You received this message because you are subscribed to the Google > Groups "ClojureScript" group. > > To unsubscribe from this group and stop receiving emails from it, send > an email to [email protected]. > > To post to this group, send email to [email protected]. > > Visit this group at http://groups.google.com/group/clojurescript. > > -- > Note that posts from new members are moderated - please be patient with > your first post. > --- > You received this message because you are subscribed to the Google Groups > "ClojureScript" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/clojurescript. > -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups "ClojureScript" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/clojurescript.
