Tell the User when/which Installed Package Crashes


#1

A lot of people seem to have been having startup crashes recently, myself included, and the cause of this is usually a package crashing on load. When this happens it requires a very awkward trial and error process by the user of doing atom --safe and uninstalling/disabling packages one at a time to determine which package has thrown a spanner into your workflow and oust it.

A safety net around the package loading process would be great, a safety net around running packages after load too would be even better. Let me know if the crash is because a package died, and tell me which package it was so I can resolve the issue quickly and easily and get back to work.

Cheers!


#2

We already have this as part of our uncaught exception handling system. Package authors get Issues opened on their packages when Atom can determine that their package is at fault for an uncaught exception. For example, here is one that was reported for one of my packages:

If you have specific examples of crashes that happened that weren’t caught and suggestions of how we can expand the support that already exists, please let us know!


#3

I’ve had multiple packages with bugs in freezing up my editor on load and I’ve always had to force quit and start up in safe mode. I’ve seen many similar topics about that issue. So is it down to the package creator to handle the exception and the editor crashing is the result of it not being handled correctly? It’s good that the package creator is notified about the exception. However a non-responsive editor isn’t ideal for the user themselves. And ideally like I said the user would be notified which package was at fault so they can uninstall it without the trial and error process.

No specific details to hand, sorry!


#4

There is a subtle difference between “crashing” and “no longer responding”. If the editor stops responding to the point where you have to force quit, then there isn’t much Atom can do in that instance to determine what package is causing the problem. If Atom had spare cycles to determine the problem, then there wouldn’t be a problem :grinning:

We’re working with the Chromium and Node teams to see about improving that situation, but it is currently an architecture problem that is somewhat out of our control right now.