I’m writing this post because there are a few times I’ve gotten this particular exception and then look at the trace and can’t figure out what’s wrong. More often than not, I’ll get to the line in the trace and be like, “wtf! there’s no priority here. It’s a method call not a constant”. This turns into, let’s see if something is happening before this method is called and finally comes down to looking at the Zend_Log source and remember, “oh yeah, Zend_Log allows you to use log by priority name as a method in lieu of using the log method” and what I once thought of as slick when I read the documentation turns into a waste of a few minutes and added amount of aggrevation. So to save myself and others some time and aggrevation, I’m going to go into a bit of detail as to why you may be getting this exception.
Take the following for example:
// assume taht $log is a valid instance of Zend_Log $log->addEventItem('foo','bar');
It looks like it should work, right? It won’t because the correct method call would be
$log->setEventItem('foo','bar');
As I explained in the introduction, the ‘bad log priority’ exception will be thrown for this sort of error. This error will occur because Zend_Log overloads the __call function so that you can do
$log->priorityName('message'); // instead of logging with the log method $log->log('message',Zend_Log::PRIORITY_NAME);
So if you’re like me and get this exception but only see a method where this error is being thrown, you now know why and hopefully be less confused and aggrevated.
I wish I could provide a solution to this issue but I see no way that Zend_Log can contextually tell if you’re wanting to use the priorityName shortcut or not. This only leaves the option of removing the the priorityName shortcut entirely, which will break somebody’s code. The shortcut is nice because of its flexibility but definitely a case where flexibility can increase complexity or rather, flexibility leading into complications that require complex understanding. I haven’t had time to read all the arguments in the comments on the flexibility/complexity issue that Federico Cargnelutti brought up recently to have an overall opinion on the matter but in regards to Zend_Log, the flexibility should’ve been left out. I would’ve preferred that Zend kept it simple and just made log the only method of logging. Or maybe I’m an edge case that logs more information than the initial event items give me.
Actually, this sounds like a classic error when using __call() — making sure that any exceptions raised actually make sense and are not context sensitive. Typically it’s best to simply raise an exception with the message “__call() is unable to trap the method $method”.
If you haven’t already, can you file an issue asking to change the exception message raised by __call() in Zend_Log?
Matthew,
I filed an issue like you suggested.
http://framework.zend.com/issues/browse/ZF-5884
I get this error when I add $log->registerErrorHandler(); to my log object