Can I use the dd() function in production?

Asked

Viewed 173 times

1

I created a function that is called in another class to perform a task during a request in a Controller of my application.

I put a return in that function to interrupt its execution in a specific situation. Only after that return, the main function of Controller continues running. I then used the function dd() of Laravel to stop all execution in this situation but, I think this function is used only for Debug.

You use this function also for specific situations in codes that are in Production or only for Debug even?

This is the function in which I inserted the dd, that is within another class:

public function verificaItens($shipmentPed,$AuxPedido){
    $pieces = explode("-", $shipmentPed);
    $tagSearch = TRIM($pieces[0]).' - '.TRIM($pieces[1]);

    $tag = \App\pedidosretira::where("shipment_tray",strtoupper($tagSearch))->first();      

    if(!isset($tag->num))
     return response("Informação de Retirada '".$shipmentPed."' não 
     encontrada na base local da integração.", 203);

    $this->num = $tag->num;
}

Below, the line calling the function inside the Controller:

$AuxPedido->verificaItens($pedido->shipment,$AuxPedido);
  • The Return should stop running your controller. Can you [Edit] your question and include the snippet of the controller code? About dd() you’re right, it’s more for debug. I recommend you return some kind of message to the user because only one return; may not make sense as a return.

  • It happens that I call this function inside a Controller but, it is in another class, it is not inside this Controller. That’s why the Controller function keeps running after this Reset. I edited the question and entered the code.

2 answers

4


It is normal the controller does not terminate the execution, as it itself returns nothing. The controller executes verificaItens but does nothing with the Response maid.

Isolate in the context of controller its logic to work with the sponses, and in its business logic implement only its business rules.

For example, update your controller and your business logic for something close to this:

public function codigoController() {

    // alguma coisa

    // atenção para a negação no começo do if
    if (!$AuxPedido->verificaItens($pedido->shipment) {
        return response("Informação de Retirada '{$pedido->shipment}' não encontrada na base local da integração.", 203);
    }

    // segue o fluxo positivo

}

In the code of your method, try to make more cohesive what that method should do, avoiding passing values not used in that method:

// $AuxPedido não é usado dentro do método, e é estranho um método receber o próprio objeto
public function verificaItens($shipmentPed) 
{
    $pieces = explode("-", $shipmentPed);
    $tagSearch = trim($pieces[0]).' - '.trim($pieces[1]);

    $tag = \App\pedidosretira::where("shipment_tray",strtoupper($tagSearch))->first();

    // assumindo que esse é um valor numérico, retorna verdadeiro se for maior que zero, 
    // ou falso se for 0 ou nulo. 
    // Não vai funcionar se for uma string (sempre vai voltar true)
    return (bool) $tag->num;
}

You use this function also for specific situations in codes that are in Production or only for Debug itself?

The dd() is used for debug same. It is not recommended to use it to close a stream. I recommend reading how the cycle of requests of Laravel to understand what happens to your code until you reach your controller.

  • 1

    Cool. Really interesting to treat the function response in the Controller. I’ll do it like this.

2

@Kênia in production generally APP_ENV=Production and APP_DEBUG=false so both exceptions and the use of dd are diverted to the log Storage logs Laravel.log, because when using dd the interruption generates http 500 Internal Server Error, for the user in production appears a standard screen of the Laravel without showing the data.

If you want to see dd you would have to change the parameters mentioned. However for production scenario is not advised because when leaving the logs and debug appearing on the screen, they bring information that can favor someone malicious. The ideal for production would be the log in the file so only you could see:

Log::debug($message);

If you want to show a message to the user this should be returned to the control, and from the control to the view.

  • Very didactic. I didn’t know dd was going to log in the presented situation.

Browser other questions tagged

You are not signed in. Login or sign up in order to post.