Ah I see your concern. That doesn't happen though. In my testing when the
daemon restarts sharejs the reconnection seems to restore instantly to
users that did not cause the exception unless they are writing at the exact
moment of restart (does that make sense). We can play around with this more
tomorrow. Further, allowing people to continue running through the process
once it has thrown an error that wasn't caught isn't recommended as the
state is brittle and unsupported.



On Wed, Dec 11, 2013 at 4:46 PM, EricByers <notifications@github.com> wrote:

> In bin/sharejs:
>
> > @@ -41,4 +41,5 @@ process.title = 'sharejs'
> >  process.on('uncaughtException', function (err) {
> >    util.puts('An error has occurred...');
> >    util.puts('Version ' + sharejs.version + ': ' + err.stack);
> > +  process.exit(1);
>
> Well we know things stay running with at least some exceptions...
>
> My concern is that whenever we exit and restart..we kick everyone out of
> the studio with a big fat error, and we want to do that as little as
> possible...
>
> I know the story is for restart, but I think the restart should only
> happen when ShareJS is completely unreachable, meaning our customers have
> already experienced errors/timeouts in waiting..
>
> —
> Reply to this email directly or view it on GitHub<https://github.com/ceros/ShareJS/pull/11/files#r8282879>
> .
>



-- 

Matt Surabian
*Ceros* <http://www.ceros.com> ◊ Senior Developer
What *is* Ceros? <http://www.ceros.com/video>
tel: 774.314.7668
skype: yuro.divy