юзайте parent::method()

 function __construct(string $db_server, string $db_name, string $db_user, $db_password = '') {
            $this -> db_server   = $db_server;
            $this -> db_name     = $db_name;
            $this -> db_user     = $db_user;
            $this -> db_password = $db_password;
        }

Вместо проверки в методе db_connect()
И пароль ведь может быть и пустым, а ... :)

И вообще то
$

connect = mysql_connect($this -> db_server, $this -> db_user, $this -> db_password) 
                           or die ($this->get_error_message(get_class(), 'ERROR_CODE_1'));

так как protected наследуется

Блин пришлось переписать

 
// Логичней определять имя класса по его аспектам знаний и требований
class Error{
        protected $error_display;
        
        function __construct($error_display) {
            $this -> error_display = $error_display;
        }
        
        // Вывод сообщений об ошибках по их коду
        protected function get_error_message($class, $code) {
           
            //Если обработка включена
            if ($this -> error_display > 0) {
                include './classes/error_codes/'. $class .'.php';
                if ($class == 'mysql')
                    $log = 'mysql.log';
                else
                    $log = 'main.log';
                
               //  Если включено логирование
                if ($this -> error_display == 1) {
                    ...
                }
                
                // Если включен вывод
                if ($this -> error_display == 2 || $this -> error_display == 3) 
                    ...
            }
        }
    }

    class mysql extends Error{
        //  Параметры соединения с базой
        // Если сомневаетесь в выборе видимости переменной всегда лучше выбирать самый радикальный
        // В этом случае эти свойства только этого класса
        private $db_server;
        private $db_name;
        private $db_user;
        private $db_password;
                
        function __construct(string $db_server, string $db_name, string $db_user, $db_password = '') {
            $this -> db_server   = $db_server;
            $this -> db_name     = $db_name;
            $this -> db_user     = $db_user;
            $this -> db_password = $db_password;
            // Передаём константу из конфигурационного файла
            parent::__construct(ERROR_DYSPLAY)
        }
        
        //  Соединение с БД
        function db_connect() { 
                $connect = mysql_connect($this -> db_server, $this -> db_user, $this -> db_password) 
                           or die ($this->get_error_message(get_class(), 'ERROR_CODE_1'));
                mysql_select_db($this -> db_name, $connect) 
                           or die ($this->get_error_message(get_class(), 'ERROR_CODE_2'));
                mysql_query('SET NAMES utf8');
                mysql_query('SET CHARACTER SET utf8');
                mysql_query('SET COLLATION_CONNECTION="utf8_general_ci"');
        }       

$db_connect = new mysql(HS_DB_SERVER, HS_DB_NAME, HS_DB_USER, HS_DB_PASSWORD);
$db_connect -> db_connect(); 
        

Но в этом случае конечно резонно было бы не наследование, так как Драйвер БД mysql "неявляется" подтипом класса обработки ошибок Error. В этом случае лучше использовать композицию и агрегировать объект $this->error = new Error(ERROR_DYSPLAY); c последующим использованием $this->error->get_error_message(get_class(), 'ERROR_CODE_2') . Что это даёт? При смене обработчика ошибок с таким же интерфейсом (методы get_error_message и ...) мы не получим конфликтов между Драйвером и обработчиком ошибок.

---

Спустя 2 минуты, 18 секунд Гость_Greg1978 написал(а):

---

И уменьшим связность двух объектов к минимуму, с дальнейшим пере использованием их отдельно.

Думается мне, что это неправильная архитектура классов.
Каким таким боком класс для работы с базой связан с классом ошибок? Это совершенно разные сущности, с какого они там наследуются?
Должно быть два объекта: объект класса работы с бд и объект класс ошибок. С ними и работай.

upd.
P.S. Гость_Greg1978 именно об этом и говорит.

Смысл в том, что все функции обращаются к одной функции обработки ошибок и она их складывает или выводит на печать при соответствующем значении ERROR_DISPLAY

TranceIT, а зачем тебе вообще класс для этого? Используй две обычных функции: add_error и print_error, плюс статическую переменную global_errors.
А коль класс хочешь, используй Синглтон, тогда у тебя также все ошибки будут в одном объекте собраны. Но второй вариант - он тут нафиг не нужен. По моему мнению. Но я за философию "просто лучше, чем сложно".

Всем большое спасибо. Почитал про агрегацию и абстрактные классы и все стало на свои места.

Смысл ошибок в том, чтоб использовать Exception. Читаем в этом направлении.

Немного запутался в определениях... Объясните мне, пожалуйста, для чего используются статические объекты?

В моем понимании, это объекты, к которым мы можем получить доступ не создавая экземпляр класса. То есть вместо:

$mysql = new my_class;
$mysql -> my_object();

Используется:

my_class::my_object();

Если я правильно понимаю, то зачем все это нужно? Не проще ли создать просто функцию? Или это используется для того, чтобы указать принадлежность данного метода к определенному классу?

В чем отличие абстрактного класса от интерфейса? Когда использовать первый и второй? 10 страниц гугла перечитал, но никак не могу этого понять... Все разъяснения настолько запутаны и перегружены профессиональным жаргоном, что превращаются просто в набор слов... Вот например:

TranceIT
Попробуй тут посмотреть. Хотя описать абстракции простыми словами - крайне тяжелая задача.

В общем ответ на первый вопрос я нашел. Правильный он или нет, я не знаю, надеюсь на помощь знатоков.

Абстрактный класс позволяет нам создавать внутри него частичную функциональность и/или описывать эту функциональность. Так же в нем указываются абстрактные методы, которые обязательно должны быть реализованы в дочерних классах. Как бы для того, чтобы программист не забыл, что тут что-то должно быть.

Интерфейсы нам позволяют только указывать на методы, которые обязательно должны использоваться.

Суть второго вопроса скорее упирается в проектирование... В сложных приложениях гораздо проще найти общие методы по интерфейсу, чем разжевывать длинную сосиску наследования...

Guest
twin
Ещё раз прочитайте мой пост, потом посмотрите на код ТС и подумайте чё вы тут ляпнули.

Так уж сразу и ляпнули...
По мне так ни вариант TranceIT, ни тем более ексепшены в данном контексте неинтересны. Причем ексепшены неинтереснее вдвойне, ибо мало того, что утяжеляют код, так еще и нещадно жрут ресурс.

А тут вполне достаточно обычного сервисного сообщения.

                $connect = mysql_connect($this -> db_server, $this -> db_user, $this -> db_password) 
                           or die ('No connect');

ибо совершенно не важно, в каком методе осуществлялся коннект, если его нет. Метод тут не виноват.

twin
Ну мне-то ты можешь не рассказывать про своё отношение к эксепшенам и ООП в целом А то, что использование исключения упрощают не только код, но и контроль за ходом выполнения приложения - это факт. Для хоумпаги, банальный die() сойдёт, для приличного приложения сообщение 'No connect' будет являться хамством.

Да ладно.
Что за такие "приличные" приложения, в которых нужно клепать кучу кода ради того, чтобы слогировать или вывести кучу совершенно незначимой и лишней информации? Ну если упал мускул, на кой мне знать, что за коннект отвечает метод db_connect(), а в твоем случе еще и то, что он находится в таком то файле на такой то строчке?

Показуха это все, раздувание ноздрей. Код должен быть максимально прозрачным и легким, вот тогда это красиво. А много лишних букаф - индуаизм.

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

Ну так то да, суть только в том, где их стоит применять, а где нет. Я именно это имел ввиду, когда "ляпал".

twin
Ну не всегда стоит глобализировать, когда речь идёт о чём-то конкретном.

Вот именно. В данном конкретном случае ексепшенам ну вообще не место) Собственно как и тому огороду, что мы видим у ТС.

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

Причемтут ООП... Тут речь вообще о применении ексепшенов вроде как. И о их месте применения.

Мы уже спорили на эту тему один раз, зачем повторяться. Ну вот допустим я не использую эксепшены, ну не нравятся они мне. И есть у меня свой велосипед, который позволяет писать код намного чище, нежели с ними. И похож он на представленный кстати.

Тогда мы пришли к тому, что исключения нельзя бросать в контексте программы, а можно только в "тонких" местах. Так я не вижу смысла до сих пор, городить тяжеловесные try... cach в таком случае, если можно пользоваться легеньким or

Ведь or не обязательно нужно сопровождать die(), можно и своей функцией/методом. А там трассируй, логируй, рисуй странички красивые, как kirik хотел или вообще делай все, что душе угодно.

Так что учеба учебой, но выбирать ему. И твоё категричное заявление

Твой вариант с or и своей функцией будет оторван от контекста - ситуации при которой произошла ошибка и в этом состоит главный минус. Другой минус в том, что в твоём случае некий участок кода привязан к тому, как должна обрабатываться ошибка, хотя это в нормальном программировании не его забота. Его проблема только "сообщить", что была ошибка, как должно поступать при её возникновении решать тому участку кода, который ожидает какого-то результата. Это есть нормально и логично. Я уж молчу о командной разработке. Мой пост не имеет смысла без

Такс.
Вот так ты предлагаешь делать, я помню:

function mega_secure_func($kode = null)
{
    if (is_null($kode))
        throw new Exception('Fatal error. Kode is null.');
}

$a = null;
try
{
    mega_secure_func($a);
}
catch(Exception $Except)
{
    die($Except->getMessage());
}

А ну ка попробуй так же раскритиковать это:

function mega_secure_func($kode = null)
{
    if (is_null($kode)) 
         exept('Fatal error. Kode is null.');
}

$a = null;
mega_secure_func($a);

function exept($message)
{
    die($message);
}

Чем сие отличается? Про командную разработку действительно стоит умолчать. Команда команде рознь.

Фишка в том, что ты возвращаешься обратно к блоку try {} catch() {} где в catch'е можешь реагировать на исключение, тем более таких вызовов mega_secure_func() может быть несколько в разных местах приложения и тем более если эти вызовы зависят от ситуации и код-реагирование может меняться в зависимости от этой ситуации. Т.е. например, в одном месте достаточно сделать die() с текстом ошибки, в другом месте что-то куда-то записать и только потом сделать die(), в третьем ещё что-нибудь. В твоём случае с одной функцией тебе придётся хреначить кучу условий под каждую ситуацию и всё это дело тащить через весь код.
Чтобы ты понял, я приведу иной пример

class User
{
    public static function getUser()
    {
        ...
        if (!$result)
            throw new Exception('Произошла ошибка');
        self::login($name, $pass);
    }

    public static function login($name, $pass)
    {
        ...
        if (!$result)
            throw new InvalidUser('Нет такого')
    }

    public static function asGuest() {}
}

try
{
    $user = User::getUser();
}
catch(InvalidUser $e)
{
    $user = User::asGuest();
}
catch(Exception $e)
{
    die($e->getMessage());
}

echo "Привет, " . $user->name;

в другом скрипте, где разрешено только зарегистрированным пользователям находится мы просто напишем

try
{
    $user = User::getUser();
}
catch(Exception $e)
{
    die($e->getMessage());
}

Таким образом мы локализуем любую проблему в приделах одного блока try catch текущей ситуации и не надо нам шариться в поисках а где же и что же сработало, мало данных echo $e->getTraceAsString(); и мы видим где и что же произошло.

Ну так а в чем разница, я так и не уловил.

Тут просто религия не позволяет писать в рамках одного проекта двух функций с одинаковыми именами, вот и все. А смысл одн и тот же. В одной области видимости и двух одинаковых catch нельзя. Так в чем разница между этим:

catch(Exception $e)
{
    die($e->getMessage());
}

и этим

function exept($message)
{
    die($message);
}

?

Вот сделают в шестой ветке неймспейсы, даже политическая окраска у ексепшенов пропадет. Потому что они громоздкие и жручие. :)

По моему разницу я объяснил и даже пример описал. А ты выдрал из контекста кусок кода не обращая внимания на его смысл в общем логическом плане. Разница в том, что я по разному реагирую на исключение, а ты пускаешь всё через одну дырку function exept($message). Ещё раз, допустим есть скрипт, в котором описан класс

class User
{
    public static function getUser()
    {
        ...
        if (!$result)
            throw new Exception('Произошла ошибка');
        self::login($name, $pass);
    }

    public static function login($name, $pass)
    {
        ...
        if (!$result)
            throw new InvalidUser('Нет такого')
    }

    public static function asGuest() {}
}

допустим есть второй скрипт, который что-то отображает для любого пользователя

try
{
    $user = User::getUser();
}
catch(InvalidUser $e)
{
    $user = User::asGuest();
}
catch(Exception $e)
{
    die($e->getMessage());
}

echo "Привет, " . $user->name;

допустим есть третий скрипт, который что-то отображает, только для зарегистрированных пользователей

try
{
    $user = User::getUser();
}
catch(Exception $e)
{
    die($e->getMessage());
}

echo "Привет зарегистрированный пользователь, " . $user->name;

вопрос в чём разница ещё возникает?

Да ипишкин кот... Это ты не можешь врубиться никак. Вот я пишу

class User
{
    public static function getUser()
    {
        ...
        if (!$result)
            exception('Произошла ошибка');
        self::login($name, $pass);
    }

    public static function login($name, $pass)
    {
        ...
        if (!$result)
            invalidUser('Нет такого')
    }

    public static function asGuest() {}
}


    $user = User::getUser();

function exception($e)
{
    $user = User::asGuest();
}

function invalidUser($e)
{
    die($e);
}

echo "Привет, " . $user->name;

и

    $user = User::getUser();

function exception($e)
{
    die($e);
}

echo "Привет зарегистрированный пользователь, " . $user->name;

1. Напутал малясь.
2. Переопределение одной и той же функции
3. Второй не учитывает exception()
4. Куча разных функций с одинаковыми названиями и разными реализациями.
5. Класс User не является самодостаточным и зависит от неких внешних функций exception() и InvalidUser().

Честно, у тебя получился говнокод полный.

Ну напутал - поправил. Суть от этого не меняется.

Из всех претензий только одна в тему - по поводу самодостаточности класса. Все остальное мимо кассы. Да и то спорно. Класс, снабженный внутренним собственным дебаггером, куда как самодостаточнее внешних try catch . А пользовательские фишки плана "Привет зарегистрированный пользователь" гораздо проще решаются ретурнами. Вернул метод false - реагируй как нужно. Причем тут же, не бегая по всему файлу в поисках блоков. А прежде чем блоки организовать - по классу. Там же тоже всякие throw new InvalidUser, а документацию похерили.

Определение говнокодинга у каждого разное. По мне так верхом говнокодинга является класс, каждый метод которого бросает исключение. Для разработки может и удобно, когда все ошибки видно в одном месте. А вот в продакшене это гири на ногах.

Иногда конечно они полезны, бывают всякие ситуации, я не то, чтобы их в штыки. Но не так фанатично лепить их куда ни поподя.

Да суть не меняется, как был говнокод с кучей нелепых функций, так и остался.

Не нужны классу дебаггеры вообще, неотловленные ексепшены отловит сам php, либо кодер вручную через set_exception_handler() пропустит через свою функцию и обработает так, как ему нужно. Ты забываешь ещё об одной важной фишке, эксепшен может возникнуть и внутри кода, который я пометил как .... Там тоже много чего может произойти и всё это локализуется в одном месте - в месте вызова User::getUser(). Потерял доку, сделай try {} catch(Exception $e) {} и посрать на твою доку. А тебя без бутылки, где и какую функцию объявлять, не разберёшься.

Холивар, короче. Знаю что бесполезняк тебе объяснять суть, но всё равно блин втягиваешь.

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

Я имел ввиду совсем не тот всторенный дебаггер, который отлавливает ошибки кодинга. Их вообще в продакшене быть не должно. А в разработке, ты правильно отметил, вполне хватает средств и бех этих монструозностей.

Я имел ввиду именно пользовательский дебаггер. Который без всяких трюков и качей выдаст ошибку использования. Допустим в почтовом классе можно сразу предусмотреть сообщение о неверно введенном мыле. Или аплоадер, который сам расскажет, почему вдруг отказался принять файл.

Такой класс куда как самодостаточнее будет. И работать с ним проще. Отработал штатно - продолжаем движение. Нет - выбираем. Либо удовлетвориться тем, что имеется в арсенале, либо реагируем иначе.

А нештатные ситуации, которые кстати мы уже обсуждали тут, совершенно не нуждаются в ексепшенах.

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

Так вот, ситуации, где ексепшены действительно полезны, можно пересчитать по пальцам одной руки.

Все остальное - чистейшей воды говнокодинг, в продакшене особенно.

И вот это

Да, это я тот, который "ляпнул". Впервые с twin во мнении сошлись
linker
Не ведись на свои чувства и тех, которые кричат что исключения это всё!!!
Докажу.
Исключения в PHP не то что в PERL (в нём это специфический принцип программирования). В любом другом ЯП, объект имеющий исключение говорит (нет наверное кричит ) "Я НЕ ЗНАЮ КАК ЭТУ ОШИБКУ ОБРАБОТАТЬ", после чего принимается обрабатывать её верхнеуровневый объект (класс) и т.д., для того их и назвали ИСКЛЮЧЕНИЯ, в полном смысле этого слова. Смысл в том что исключения сейчас используют в контексте "перескакивания" алгоритма обработки, это с PERL, и это довольно спорно.
Но, могу конечно привести ситуэйщин, когда нужен вверх нисходящий поток в любых раскладах. Это несостоятельность перехвата AJAX от сервера исключениями и вывод ощибок самого PHP в формате сигнатуры типа (function (string $string){}), при котором передаваемый параметр не string. Вот где исключение, это не известная ошибка, которая в результате не понятных причин выскочила за рамки, тем более что исключение, которое не перехвачено ajax - ом не выведится, а будет просто HTML только пустой. А о том что класс USER отдаёт свою ошибку и говорит что я не могу с ней справиться - это глубокая ошибка её отдавать наружу. Почему? Потому как мы этим говорим всем "клиентам", использующим наш класс что у нас оказывается есть ещё проблемы, которые мы не в состоянии решить, хотя эти проблемы нашего (классового) уровня.