Tickets :: [#8041] User-facing notifications shouldn't contain stack traces or talk about exceptions

6.0.0-alpha14

7/2/25

Summary	User-facing notifications shouldn't contain stack traces or talk about exceptions
Queue	IMP
Queue Version	Git master
Type	Bug
State	Resolved
Priority	1. Low
Owners	slusarz (at) horde (dot) org
Requester	chuck (at) horde (dot) org
Created	03/02/2009 (5966 days ago)
Due
Updated	06/30/2009 (5846 days ago)
Assigned	05/22/2009 (5885 days ago)
Resolved	06/30/2009 (5846 days ago)
Github Issue Link
Github Pull Request
Milestone
Patch	No

06/30/2009 06:47:02 PM	Michael Slusarz	Comment #9 State ⇒ Resolved	Reply to this comment
Going to close this. We can deal with these errors when they show up.

05/29/2009 05:45:51 AM	Michael Slusarz	Comment #8	Reply to this comment
Nope - I still get exception message from git IMP (when I take too long to use a link, for example). Did somebody revert all the changes I made where I was passing the Exception object directly to the notification stack? I haven't touched any of them. It's probably easiest to simply pick them off one-by-one as they are encountered instead.

05/22/2009 08:27:31 PM	Chuck Hagenbuch	Comment #7 State ⇒ Assigned	Reply to this comment
Nope - I still get exception message from git IMP (when I take too long to use a link, for example).

05/19/2009 03:02:50 PM	Michael Slusarz	Comment #6 State ⇒ Resolved	Reply to this comment
Resolving for now, since I believe my initial commits have been backed out over the last few months.

03/02/2009 11:55:53 PM	Jan Schneider	Comment #5	Reply to this comment
As far as I understood the outcome was just to not use error/exception codes for notification classes. My "if you really want" was rather pointing at the fact that we didn't talk about how to deal with exceptions in the frontend in H4 at all. Pushing them as notifications might still be the best solution, but since we re-think everything, someone might come up with a better idea. And to voice my opinion: I still like notifications, though we might also need a general handler for uncatched exceptions. Heck, I wrote that stuff 7 years ago. :-)

03/02/2009 11:33:28 PM	Michael Slusarz	Comment #4	Reply to this comment
I don't agree. Pushing exceptions should be as easy as pushing PEAR_Errors. If necessary we should refactor Notification instead. I guess I am confused, since I thought you were arguing for exactly the opposite here: http://lists.horde.org/archives/dev/Week-of-Mon-20090223/023797.html I want to be able to push Exceptions onto the Notification stack, but I thought that I had been outvoted re: this issue.

03/02/2009 11:11:38 PM	Jan Schneider	Comment #3	Reply to this comment
I don't agree. Pushing exceptions should be as easy as pushing PEAR_Errors. If necessary we should refactor Notification instead.

03/02/2009 10:28:30 PM	Michael Slusarz	Comment #2	Reply to this comment
This is probably better described as removing all of the following from IMP: $notification->push($e) where $e is an Exception, and replacing with: $notification->push($e->getMessage() [, $e->getCode]);

03/02/2009 10:08:17 PM	Chuck Hagenbuch	Comment #1 State ⇒ Assigned Patch ⇒ No Milestone ⇒ Assigned to Michael Slusarz Queue ⇒ IMP Summary ⇒ User-facing notifications shouldn't contain stack traces or talk about exceptions Type ⇒ Bug Priority ⇒ 1. Low	Reply to this comment
Example: exception 'Horde_Exception' with message 'This request cannot be completed because the link you followed or the form you submitted was only valid for 30 minutes. Please try again now.' in /var/www/horde/horde-hatchery/imp/lib/IMP.php:138 Stack trace: #0 /var/www/horde/horde-hatchery/imp/compose.php(117): IMP::checkRequestToken('imp.compose', 'VTpiA2aW_Z5yeLN...') #1 {main}