sql >> Databasteknik >  >> RDS >> Mysql

mysqli or die, måste den dö?

Måste den dö

Tvärtom, det borde inte or die() någonsin.
PHP är ett språk med dålig ärftlighet. Mycket dålig ärftlighet. Och or die() med ett felmeddelande som ett av de värsta rudimenten:

  • die slänger ut ett felmeddelande som avslöjar några systeminterna delar för en potentiell angripare
  • det förvirrar oskyldiga användare med konstiga meddelanden och lämnar dem inget gränssnitt att arbeta med, så de skulle förmodligen bara hoppa av.
  • det dödar skriptet i mitten, så det kan orsaka trasig design (eller ingen design alls) som visas (dvs. en ofullständig rendering av sidan som användaren begärde)
  • dödar skriptet oåterkalleligt. Medan det kastas kan undantag fångas och hanteras på ett elegant sätt
  • die() ger dig ingen antydan om platsen där felet uppstod . Och i en relativt stor applikation kommer det att vara ganska jobbigt att hitta.

Så använd aldrig die() med MySQL-fel, även för den tillfälliga felsökningen :det finns bättre sätt.

Istället för att manuellt leta efter felet, konfigurera bara mysqli att kasta undantag vid fel genom att lägga till följande rad i din anslutningskod

mysqli_report(MYSQLI_REPORT_ERROR | MYSQLI_REPORT_STRICT);

och efter det skriv bara varje mysqli-kommando som det är, utan någon or die eller något annat:

$result = mysqli_query($link, $sql);

Den här koden ger ett undantag i händelse av fel och du kommer därför alltid att informeras om varje problem utan en enda rad med extra kod.

En mer detaljerad förklaring om hur du gör din felrapporteringsproduktion klar, enhetlig och överlag vettig samtidigt som du gör din kod mycket renare, hittar du i min artikel om PHP-felrapportering .



  1. Inkrementell belastning i SSIS

  2. SSIS källformat Implicit konvertering för datum och tid

  3. Drivrutinen kunde inte upprätta en säker anslutning till SQL Server genom att använda Secure Sockets Layer (SSL)-kryptering

  4. Hur gör man två frågor med vanliga kolumner (A, B) och (A, C) till bara en (A, B, C)?