-
-
Notifications
You must be signed in to change notification settings - Fork 604
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Split Whoops into separate handler & display projects #556
Comments
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 |
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 :) |
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. |
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. But ideally the error handler is one vendor, then the displaying would be another. |
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. |
@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. |
Just make sure you dont register the pretty page handler and use the exception mechanics for another handler abd you are good to go |
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. |
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 |
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 If it’s well designed, I’d be happy to recommend it in place of Whoops core, which by today is a bit dated. |
ok I'll see what I can do in that direction |
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
The text was updated successfully, but these errors were encountered: