2010-05-07 3 views
1

У меня есть пользовательский класс, который при вызове перенаправляется на страницу и отправляет переменную message_type и message через GET. Когда страница открывается, она проверяет эти переменные и отображает сообщение об ошибке «успех», «предупреждение» или «ошибка» в зависимости от переменной «message_type». Я сделал так, чтобы пользователь подумал, что они остаются на одной странице. Он также позволяет передавать другие переменные вместе с сообщением.Обработка ошибок в PHP

Является ли это хорошей практикой, или я должен просто начать использовать исключения?

Пример:

//Call a static function that will redirect to a page, with an error message 
RedirectWithMessage::go('somepage.php', MessageType::ERROR, 'Error message here.'); 

Следующая функция checkMessage() представляет собой файл, включают в себя:

function checkMessage() 
{ 
    if((isset($_GET['message_type']) && strlen($_GET['message_type'])) && (isset($_GET['message']) && strlen($_GET['message_type']))) 
    { 
     DisplayMessage::display($_GET['message_type'], $_GET['message']); 
     return true; 
    } 
    return false; 
} 

На странице, которая перенаправляется на, вызовите checkMessage();

//If a message is received, display it. If not, do nothing 
checkMessage(); 

Я знаю, что это может быть расплывчатым, и я могу предоставить больше кода, если это необходимо. Я думаю, проблема в том, что у меня нет большого опыта использования исключений, но я думаю, что они кажутся громоздкими (пишущие блоки try-catch повсюду). Пожалуйста, дайте мне знать, если я сделаю это более сложным для себя или если будет лучшее решение.

Спасибо! Mike

ответ

1

Я думаю, что это хороший способ сделать это, я делаю что-то очень похожее, хотя вместо этого сохраняю соответствующую информацию об ошибках в их сеансе ($_SESSION) и очищаю ее сразу после ее отображения. Это исключает его из строки запроса и делает это так, если они обновляют страницу. Ошибка исчезла.

+0

Спасибо, Майкл. Мне нравится идея сохранения сообщения в переменной $ _SESSION. Мне не понравилось, что сообщение остается, когда страница обновляется. –

0

Я не уверен, что блоки Исключения и Try/Catch - это путь, но вы можете создавайте свои сообщения об успехе или ошибке на одной странице без необходимости перенаправления на другую страницу.

Кроме того, эта корректировка в вашем состоянии, если немного легче читать и должны достичь тех же результатов:

if(!empty($_GET['message_type']) && !empty($_GET['message'])) 
+0

Я читал, что empty() не самый надежный способ проверить, содержит ли переменная информацию. Но вы правы в том, что читать легче. Я только что переключил его на вашу версию. Благодаря! –

0

Я использую «если» проверить много, потому что я никогда не понимал TRY/поймать обработать. Мне нравится идея помещать ошибку в $ _SESSION.

0

Одна вещь состоит в том, что похоже, что ваша бизнес-логика может быть привязана к страницам PHP, на которых она выполняется, и поэтому, если вы хотите повторно использовать некоторые из них в другом контексте, вы можете блокировать, так как вы бы застряли с перенаправлением на определенную страницу с ошибкой.

Если вы воспользовались исключениями, у вас будет возможность немедленно удалить и устранить эту ошибку или позволить ей обрабатываться выше (например, отказ от страницы и отображение страницы ошибки пользователю).

+0

Спасибо Том. Я не уверен, что я точно следую. Не могли бы вы описать, что это связано с страницами PHP, на которых работает код? –

+0

@Mike: Я имею в виду, что если вы попытаетесь использовать его в другом проекте или что-то еще, вы можете бороться, так как вся обработка ошибок жестко закодирована, чтобы пользователь мог перейти на другую конкретную страницу. но это не может быть проблемой в вашем случае. это была просто мысль. –

+0

Gotcha, спасибо! –

1

Ошибки и исключения не являются одинаковыми. Исключения представляют собой ошибки, которые являются «исключительными» обстоятельствами, такими как невозможность подключения к базе данных, неспособность ссылаться на внешний ресурс или, возможно, пользовательскую запись, которую вы считаете исключением, которая заставляет приложение останавливаться.

Учитывая, что с использованием исключений вы можете внедрить ошибки в ваших моделях/бизнес-объектах и ​​просто поймать ошибку как высоко в стеке вызовов (идеально в контроллере или главной странице, если вы не используете шаблон MVC). Если вы хотите отправить сообщение напрямую, это нормально, но вы можете просто использовать коды ошибок, чтобы вы могли просто создать объект или массив ошибок с их соответствующими сообщениями или даже поддерживать локализацию или варианты сообщений одной и той же ошибки. После того как вы поймали ошибку как исключение, вы можете затем ее загрузить в переменную и просто отобразить ее в шаблоне или в представлении или перенаправить на общую страницу сообщений.

<?php 
    class SampleModel 
    { 
     public function validate($params) 
     { 
      if (!is_array($params)) { 
       throw new Exception("Input provided is not valid"); 
      } 
      //add as many validations as you want. 
      return TRUE; 
     } 
    } 
?> 

Использование:

<?php 
     $model = new SampleModel(); 
     $input = "not an array"; 
     $msg = null;  
     $msgtype = null; 
     try {  
      $result = $model->validate($input); //this will throw a user-defined exception because we are passing a string instead of an array 
      if ($result) { 
       $msgtype = "success"; 
       $msg = "Successful validation"; 
      } 

     } catch(Exception $e) { 
      $msg = $e->getMessage(); 
      $msgtype = "Fatal error"; 
     } 

     RedirectWithMessage::go('somepage.php', $msgtype, $msg); 

Если вы не абсолютно необходимо перенаправить, просто загрузить другой набор шаблон страницы для является тип ошибки.

 //load the appropriate template/view class. You need to create this class or use a framework. 
     LoadWithMessage::display('sometemplate.inc.php', $msgtype, $msg); 

Образец кода, как правило, является контроллером.

Кроме того, есть накладные расходы на производительность для $ _SESSION, не говоря уже о дополнительной задержке, когда вы отправляетесь на рассылку (если ожидаете, что ваше приложение будет большим). Я бы не советовал использовать его для сообщений об ошибках. Обычно я просто использовал его для сохранения данных. Сообщения об ошибках не предназначены для сохранения, а сеть не имеет характера.

+0

Вау! Спасибо. Я думал, что в этом было больше. Я должен посмотреть на это утром. –

Смежные вопросы