Split Whoops into separate handler & display projects

[pursehouse]

Obviously a lot of work goes into both the display aspect of things and the error catching/handling/reformatting side of things.
It would be nice if the actual data manipulation side of things was a separate projects from the display side of things. This way the handler side of things could be utilized for a few concepts:

• on production for better error reporting/consolidation
  this would mean the core code could be used on production for sending data to things like Sentry and spawn more composer projects for local error handling systems without those projects needing to start from scratch. Without having the display side of things active/existing on production.

• 3rd party developers could build more UI concepts based on the Whoops handler system
  this could spawn a great variety of dev error display concepts because those developers would only have to worry about UI ideas and not build all the core handler code from scratch.

something along the lines of Flip/WhoopsDisplay & flip/WhoopsHandler or whatever you like..
thanks! hope you like the idea

[denis-sokolov]

I agree with that, but it’s a big effort at a time when the project is already in a slow maintenance mode. I’ve added it on the list of the hypothetical project items, but unless someone with an effort to invest comes in, it won’t magically happen. =7

[pursehouse]

well I actually already did it for internal use at work, but I could work on redoing it clean for the public project if I knew it would be adopted and maybe if the admins/whatever of the project agreed on some structure guidlines before I make something that'll be rejected because of x/y/z whatever reason :)

[denis-sokolov]

I’m open to the idea in general, but I am cautious. It would help if you could show the current in-progress work, or even just a plan. If you decide to share that, you can do it either here, or you can send it directly to me.

[pursehouse]

well the version I did is done. I ripped things apart and customized it for something else, but it wasn't intended to be reused by the central project.
Essentially I made it so that the display Handlers are a separate vendor that uses the main vendor just holding the error catching. So the definitions of error handling came from the PrettyPageHandler vendor, and the main vendor is essentially inert until the display handler project enables it. But my workings were a bit quick and dirty so I'd redo from scratch.
But ideally the setup I envision would have all the complex organizing/catching of errors put into one project, then the separate project would be very light with display code and basically just call a method in the main project to set things up. Passing the display handler into the main project handler tracking.
Off the top of my head there was a decent amount of code mixed into some classes that would need to be split apart. I'll have to review again.

But ideally the error handler is one vendor, then the displaying would be another.
so a separate vendor could use the main vendor and do storage of the errors instead of display, then later the display vendor could be used by an admin tool to review errors that were stored in a database/files.
so.... 3 vendors! haha

[staabm]

In case you mean with "3 vendors" that whoops should be splitted into 3 separate projects I would disagree.

separation of the aspects in different classes could be done though.

[pursehouse]

@staabm then that defeats the purpose of the idea. For instance I can't have whoops installed on prod because I can't risk errors showing to users. But if there was a separate logging system that ran off whoops core, then I could use that on prod.

[staabm]

Just make sure you dont register the pretty page handler and use the exception mechanics for another handler abd you are good to go

[pursehouse]

It would be a huge security risk to let code that can read the files and display them exist on a production server. Not to mention the other aspects I mentioned of reusing the same view code to review current and recorded errors from product in an admin tool reading a database.

[pursehouse]

also the system is setup to send errors as uncaught exceptions, so it forces the page load to end. so even with allowExit false, the page still stops because of the handleError method throwing the exception

[denis-sokolov]

I think it would be best if you started a freshly designed error handling tool, and accept 3rd-party UI renderers. Then Whoops would be such a 3rd-party UI renderer. Most people use Whoops as the UI first and foremost anyway.

Ideally, your tool would start with supporting our Handler interface which would make it compatible and much easier to get traction.

If it’s well designed, I’d be happy to recommend it in place of Whoops core, which by today is a bit dated.

[pursehouse]

ok I'll see what I can do in that direction