Dd, logging enhances the debugging and testing experience
Note: this article is for TP5.0, due to different versions of TP compatibility problems, the following content is for reference only.
In the last article, we talked about replacing the Collection component. Yes, there is a component for dd. Anyone who hasn’t used a Laravel doesn’t know what a DD is. Dd is short for Debug Dump or Data Dump. I’m sure you’re aware that this is a debugging tool. You haven’t used it. You don’t know how powerful it is. It runs on symfony var-dumper and Collection. If you don’t want to install Collection, just install DD. How? You can install Larapack/DD, which components are stripped from the same Laravel framework. Once installed, you can debug your code using DD.
But it doesn’t end there. You can also in the application/common/exception in the file, the following line of code in the dd. That way, every time you make a mistake, you get the dd result. As anyone who has used Laravel knows, a TP error ends up showing a Web page that is mostly useless except for wasting time.
Why dd? Because there are a lot of forms submitted, especially when you’re dealing with complex formats like JSON, where THE TP just tells you, “undefined offset 0”. The tp developer is product-conscious when it comes to this kind of problem, and he probably thinks it can’t go wrong. However, it is this kind of complex multi-table union update, which seems to be a brilliant feature, that ends up killing you. Sometimes people can’t get it done for hours. And, this problem, many white programmers have to use Xdebug single step debugging. If you switch to DD, it will take minutes. But after solving the problem, some programmer said, “I wanna kill him!” It’s obvious how much hatred he has for TP developers. The code is as follows:
namespace app\common\exception;
use think\exception\Handle;
use think\Log;
use Exception;
/** * Override Handle's render method to implement the custom Class ExceptionHandler message@package app\common\library\exception
*/
class ExceptionHandler extends Handle
{
private $code;
private $message;
/** * Output exception information *@param Exception $e
* @return \think\Response|\think\response\Json
*/
public function render(Exception $e)
{
if ($e instanceof BaseException) {
$this->code = $e->code;
$this->message = $e->message;
} else {
if (config('app_debug')){
dd($e); // Add this line and the error message will be all provided by DD!! The next line is not executed
return parent::render($e);
}
$this->code = 500;
$this->message = $e->getMessage() ? :'Sorry, internal server error';
$this->recordErrorLog($e);
}
return json(['msg'= >$this->message, 'code'= >$this->code]);
}
/** * Write exception to log *@param Exception $e
*/
private function recordErrorLog(Exception $e)
{
Loggy()::write('error'.$e->getMessage() ." \r\n ". $e->getTraceAsString()); // Write your own exception log, no longer call tp's log.
// Log::record($e->getTraceAsString(), 'error');
// Log::record($e->getMessage(), 'error');}}Copy the codeReturn parent::render($e); This is the error page for TP. Anyone who has used this error page knows how useless it is. Switch to DD output, instantly refreshed.
The cascading update table update error is only one area where TP is prone to error, because it does not validate incoming data. But this is just the tip of the iceberg. Because, if you look at Github, TP has only 29% code test coverage, and is completely using users as guinea pigs. So you never know what else could go wrong. Only when you encounter it will you find it.
What to do? The best way to prevent accidents is to monitor them all the time. The best tool for monitoring is a log. Laravel chose MonoLogo for all his great frames. Let’s pick that, too.
In addition, debugging is not just development, but also error tracking that runs online. The biggest dependency is logging. But 90% of TP logs are nonsense, and there is no support for file-by-channel logging. What to do, the MonoLogo component is still recommended. Installation is fairly simple and can be done directly in Composer.
composer require monolog/monolog
Copy the codeHowever, be careful before you install it. Commit your code to SVN or Git first, because you don’t know when it’s wrong, and when it’s wrong, the thinkPHP directory becomes the topThink directory, which you can manually delete and copy and restore. Otherwise, your project is dead. The reason? Because TP does not indicate conflict in composer. Json. Composer will of course upgrade you to 5.1 when you run it. This level of error, for open source developers, is a kindergarten class. But this kind of mistake directly destroys the project. So, if you don’t prevent, cry.
Of course, just because You have MonoLogo installed does not mean you can channel logging. This is because the demand for sub-channels is the demand of experienced people. However, there is no component for a sub-channel for TP. How to do? Fortunately, the Laravel framework has such a component called Tolawho/Loggy. Of course, you can’t install it, but you can copy Loggy’s source code and use it with the stream/handler and Stream/Writer code. This code has code for Laravel Faced and serviceProvider, tp does not and is not needed. Config is used to check channel validity. The advantage is that multiple channels can be written simultaneously for the same type of fault. In this case, it is not limited to files, but also can have SMS, mail channels, etc.
Once you’ve done that, you can write a helper function that gets Loggy’s static class. Thus, there is no need to use use backwards to introduce Loggy. In the code above:
Loggy()::write('error'.$e->getMessage() ." \r\n ". $e->getTraceAsString());
Copy the codeThat’s how it works.
At this point, you can turn off the nearly useless TP Log. Of course, how to turn it off, you grind it out. Because some of the things that need to be changed to TP, a lot of them are like the shotgun fixes in refactoring: Improving the Design of Existing Code. It’s too painful.