6.0.0-RC7
6/20/26

[#8041] User-facing notifications shouldn't contain stack traces or talk about exceptions
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 3/2/09 (6319 days ago)
Due
Updated 6/30/09 (6199 days ago)
Assigned 5/22/09 (6238 days ago)
Resolved 6/30/09 (6199 days ago)
Github Issue Link
Github Pull Request
Milestone
Patch No

History
26 Michael Slusarz Comment #9
State ⇒ Resolved
Reply to this comment
Going to close this.  We can deal with these errors when they show up.
515 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.
318 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).
503 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.
5311 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. :-)
2811 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.
3811 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.
3010 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]);
1710 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}

Saved Queries