I've created a simple class LogHelper with a static method that I call within my application. I can call it as follows:
LogHelper::writeToErrorLog($config->getLogPath(), $exception); or
LogHelper::writeToErrorLog($config->getLogPath(), $exception, $config->getLogFile);
The writeToErroLog method will generate a log filename if one isn't passed into it.
I have another class called Config, which basically takes an XML file and exposes the values via getters & setters. This is initialised at the start of the app & contains the log path where the error logs need to be written to.
My requirements are that I create one log file with the same filename per run of the application. When the app ends the logs, if populated, will be emailed.
My application has numerous other classes for DB, parsing data, formatting data, etc... all requiring logging at some point. The majority of my errors will come from exceptions thrown which will bubble up to the parent class, caught & handled by the LogHelper. There will be several cases where I don't want to throw exceptions and will just want to log information or errors.
My concern is that I feel like I'm constantly passing the config to every class that requires logging, which feels wrong. In addition I only want to be setting the filename for the error log once. Is there any best practice way of approaching this?
TIA
Stuff
Have you considered using set_exception_handler()? You wouldn't have to put the logger in every class, it would simply handle all uncaught exceptions. You could call it within your bootstrapping process or some other application initialization spot as such:
set_exception_handler(array("MyClassName", "functionNameHere"));
Inside that function you could call LogHelper::writeToErrorLog().
Related
Consider a web application that is made up of several classes. Each class has its own client - program/script that creates an object of the class.
The question is this, when a client creates an object or uses a method of a class/object, and something goes wrong in the class, should:
class terminate the application
class return a false and it's up to client to take proper action
throw and exception
Which one of these is considered best practice?
Throw an exception. It's the cleanest way to handle the abnormal situations.
Never terminate the application from inside a function of a method. They should not know about the context where they run. Throw an exception (or return FALSE/NULL/empty string/whatever is most appropriate for your application) and let the higher level code (the caller) decide how to continue.
I'd say it depends on a size and complexity of your code base, you could use any of those methods depending on a case, but the most professional one to use would be class return a false and it's up to client to take proper action.
With your own debug class it could decide what to do next, i.e. destruct class instances, close file handles, flush buffer, like I said depends on your code base. It's a good habit to handle errors with a custom error/debug class.
Hope that helps you.
Depends why it failed i guess. without knowing what the situation is, i would say to display a 404 page.
I have a master class, DBAPI which contains all the interaction with the database. It's not singleton per se, but is designed to only be instantiated once as $DBAPI.
When I alter the database, I obviously have to add functions to DBAPI to let the site use the new functionality, however, since there are a lot of different actions that can be taken, instead of including everything in a single massive class file, I've split them out by functionality/permission level as traits, and the DBAPI class file is dynamically created by adding traits flagged based off of permission level (read only, read-write etc.). Since the only time the file needs to be created is when new traits are added, I only create the class file if it doesn't exist for that specific user permission level, otherwise I use the already generated file. (If there's a better way to do this I'm all ears).
The issue I'm running into now is that if I add some functions in a new trait, the previously generated classes are obviously not aware of it, and I don't find out about that until I try to use the function in the code somewhere and it fails. It's pointless to write wrappers around every single function call made to check if it is a function first- is there some way to get the DBAPI class to do some action if code attempts to access a method it can't find?
for example, if code calls some function $DBAPI->newfunction() $DBAPI handles the exception itself, running some code that will attempt to update itself, which will cause newfunction() to run if it can be found.
(N. B. This architecture has a really bad code smell. I'm sure there's a better way to do this.)
PHP classes can implement the __call magic method that is used when there is no matching method name.
function __call( $name, $arguments ) {
// Code to run...
}
As shown in the php documentation is it possible to create your own exception handler. I see this as a reasonable way to handle my user generated errors and exceptions throughout the project I am working on. Through research I have made a decent amount of progress in implementing a specific one, just for one class, including things like using ErrorException (from the first answer) and making sure to return false for error levels that I can't handle.
I have however run into a wall with making it more generic. I don't want to have to write a separate handler for every class I write (especially because the vast majority of that code is going to be the same for every one). Yet it feels like terribly bad practice to have every single error for the entire project in the same handler.
The closest I have gotten to what feels like an acceptable solution is to write a subclass of ErrorException for every class I want to handle the errors for and store messages in each of those. But even with this I am probably going about it wrong (I don't think that would be the proper place to store default error messages). Is there a universally accepted way of doing this that I have been unable to find? or is one of these ways actually the way it's generally done? or are there multiple solutions that are scalable based on the size of the project?
EDIT: Just realized I can write a generic Exception_Handler with the reused code and extend it for each set of errors I have (real herp moment for me), but it still seems like I should handle all errors in the same place. If I'm completely wrong, let me know.
EDIT 2: Decided to go with a config file containing the error messages for each class that will throw errors, then the name of the class that throws the error defines what config file is loaded to get the list of messages associated with error number. This also allows me to easily define messages that should get logged as opposed to messages that should get sent to the user (essentially specific vs. generic messages).
I guess I'll mark this as answered or something, but if I'm doing something wrong feel free to let me know, help is always appreciated.
Decided to go with a config file containing the error messages for each class that will throw errors, then the name of the class that throws the error defines what config file is loaded to get the list of messages associated with error number. This also allows me to easily define messages that should get logged as opposed to messages that should get sent to the user (essentially specific vs. generic messages).
More specifically I'll probably use an ini file that defines an array of arrays where each number contains the array of error messages for that error number. Then use a foreach with the thrown error numbers to return the error message(s).
I have been using a controller method post directly to perform some db and social network operations but im finding a few points of failure between it and the hardware — so I came up with the idea of storing all the request in a db table to be used as a queuing system instead so I can process them in my own time rather than real time
The thing I'm struggling with now is handling my requests . I know this isn't very MVC — but its quick fix.
How do I call another controller's method from within my process queue method? I have tried including the file and instantiating it — then passing it the variables i would have done from the web.
function process(){
$result = $this->mque->get_all();
include('post.php');
$get = new post();
foreach($result->result_array() as $item){
$get->index($item['rfid'],$item['station_id'],$item['item']);
}
}
but i get an error- when i call the normal index method- it runs fine but i get an undefined method error when call it through the instantiated class method- (this is my problem)
Message: Undefined property: post::$db
The why
I am setting the process queue method to run based on a cron job running at a set interval of time.
Originally everything ran to index method of post — but since post::index() can take 10-15 seconds to run and the reader is not multi threaded — someone could use the reader within 7 seconds and the script wouldn't have run completely.
Is there a better way of doing this rather than using my current process method?
update
there is two ways to do this- either use php to fopen/get from the web
or do it sprogramming using $class->method()- i would prefer to do this the first method but dont really see any option with the error i mentioned before
That's easy: you don't have one controller call another. As a rule, if you need something to exist in two different places, you have two options:
Have them both subclass the same object
pro: That way the method is already there
con: You can only subclass one thing, and you have to build your own class loading system (NOT GOOD)
Have a library (or model) which they both share
pro: The method can then be tested better (it is (or it was at one point) easier to unit test models than it is to test controllers), the code can be shared without a custom class-loading syntax.
con: This may involve a little refactoring (but it should be as easy as moving the code from the controller's method to a library's method and then simply calling the library in the public controller method).
Either one of those would solve your particular problem. Personally, because of how CI loads controllers, my preference is to create libraries.
CodeIgniter: Load controller within controller
Is this something that could help you out quickly? Check the bottom reply.
I am just now switching back to PHP after enterprise open-source Java development for three years. Now I am tasked with updating our platform for better logging.
I now understand better how the PHP object lifecycle regarding when objects are garbage collected and have trapped my problem. I am trying to invoke the logger after its already been destructed, when a fatal error occurs. My question is, how do I fix this? How can I stop an object from being destroyed until the end of the request?
Ideally I would like to keep this logger around in memory like I would in Java but is that even possible with PHP? Is there anything shared between two different threads or requests?
With PHP, each request is processed by a different process -- which means you quite cannot keep some object arround between requests (you could serialize it and store it in a file or something like that, and un-serialize it when another requests comes ; but that's not really the way things are generally done)
This means each time your PHP script receives a request, you have to re-instanciate your logger.
Now, if you want to use your logger from several different classes/methods/functions in the same script, you have to know that variables are not global "by default" in PHP : a variable declared outside of a function is not accessible from inside a function, unless you said so using the global keyword.
In this kind of situation, when you want one and only one instance of a specific class (your logger) available from anywhere in your application, people often use the Singleton Design Pattern.
It'll allow to use something like this :
My_Logger_Class::log('blah');
From any portion of your code, and the log method will deal with :
instanciating the class if there was not already one existing instance
the actual logging
And, yes, the first time this method is called for one HTTP request, it'll have to re-open the log file (if logging to a file).
As a sidenote : there are already some existing great logging components, like PEAR::Log or Zend_Log.
Maybe using one of those might help you spend less time re-inventing some wheel ?