Closed (fixed)
Project:
Drupal core
Version:
8.0.x-dev
Component:
menu system
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Issue tags:
Reporter:
Created:
19 Jul 2013 at 02:51 UTC
Updated:
29 Jul 2014 at 22:40 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
pwolanin commentedComment #2
Crell commentedThis seems reasonable to me.
Comment #3
tim.plunkettSorry, but this needs tests.
I'm curious to see the circumstances when this happens.
Comment #4
pwolanin commented@tim,plunkett - I was seeing this when having issues with the system paths generated by the local task plugins. I was getting an uncaught exception, instead of e.g. a missing tab.
Comment #5
tim.plunkettDepending on the circumstances, it might make more sense for the calling code to catch the exception.
Comment #6
tim.plunkettTagging.
Comment #7
pwolanin commentedSince the function is currently documented as only returning TRUE or FALSE, we should make such a change in a bigger scope.
This adds a small test case to make sure there's not an exception.
Comment #8
dawehnerMh, is it okay to throw away the exception message?
Comment #9
pwolanin commented@Dawehner - I don't think there is any message? If there was what would we do with it?
Comment #10
dawehnerFor #2044969: Break the old router for contrib it would have made sense to provide a help message for the developer.
Comment #11
dawehnerMaybe we could at least write a watchdog entry?Well, having an access denied is kind of a common event.
Comment #12
dawehnerComment #13
catchAccess denied isn't that common if you're developing, I think a watchdog would be worth adding.
Comment #14
dawehnerWell, the problem is that this is also triggered when you just have a menu with a link. This would create multiple watchdog entries on every request containing a menu.
Comment #15
tim.plunkettAFAIK this isn't triggered at all in HEAD yet...
Comment #16
dawehnerSo you agree that we should add a watchdog entry?
Comment #17
tim.plunkettI wish I had called it
_menu_item_route_access().This wasn't intended to be called willy-nilly.
The test is pretty bogus, since it purposefully calls it with a known broken value.
It doesn't illustrate why that would ever happen in reality.
I personally think this exception should be either uncaught, or at least put into watchdog. Definitely not okay to silently eat the exception.
Comment #18
dawehner@peter
When did you ran into the problem with the exception?
Comment #19
tim.plunkettThis is breaking my screen
Comment #20
pwolanin commented@dawehner - I saw this when developing and the language prefix wasn't stripped from the path. so, I'd agree this other exception would often be a developer error.
Comment #21
tim.plunkettComment #22
pwolanin commented@tim.plunkett - do we really want to re-throw rather than logging it? At that point let's just close this issue.
This function is kind of a hack that we should mark deprecated by release time anyhow.
Comment #23
dawehnerIf this really just happens when you develop then throwing an exception is the best thing you can do in my perspective. Fail as early as possible is great, as you have still the context why things are broken.
Comment #24
tim.plunkettThe exception that is thrown gives you no helpful information, so I think catching it and throwing a better one is our best bet.
Comment #25
tim.plunkettThis improved exception helped me a bit with #1987762: Convert node_add_page() to a new style controller.
Comment #26
dawehnerWhat about throwing a better exception in the first place.
Comment #27
pwolanin commentedWe should annotate the function, and we no longer need the use statements in menu.inc.
Comment #28
dawehnerGood catch! It seems fine that this issue is RTBC now.
Comment #29
tim.plunkettOh, I didn't know that we threw it, thought it was upstream! That's much better. Thanks @dawehner and @pwolanin
Comment #30
catchMuch better!
Committed/pushed to 8.x. Thanks1