как и везде. http://php.net/manual/en/language.exceptions.php

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());
}

Злые вы
Вот тут посмотри

twin
у тебя добрее, можно подумать...

У меня хоть русские буквы есть)))

UPD Кстати, когда писал, пересмотрел кучу материала. Если кто найдет более легкое описание, подскажите. Любопытно.

Попытаюсь показать, почему ответ linker'а мне более симпатичен.

у него в основном потоке вычислений (довольно куцем, но тем не менее потоке) :

mega_secure_func($a);

нет и намека на проблемы. И так и должно быть.

А у тебя что здесь

    if(!$f = fopen('dummy.txt', 'a+'))
        throw new Exception('Не могу открыть файл dummy.txt');

что здесь

 
 $f = fopen('dummy.txt', 'r') 
      or except('Не могу открыть файл dummy.txt');   

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

Ну это из той же оперы, что оффтоп по FAQ. Я там промолчал, потому что были двойственные чувства.
Разумеется обертки куда как предпочтительнее, по mysql_query кстати я давным давно предложил такую штуку.
Но с другой стороны для этого нужно созреть, сам механизм обработки ошибок легче понять, когда она в основном потоке.

Однако вот тут немного все же не согласен. Вот тут

 $f = fopen('dummy.txt', 'r') 
      or except('Не могу открыть файл dummy.txt'); 

функция except() и является своего рода оберткой, которая при желании слогирует ошибку или просто запретит вывод в поток. Больше в неё передать нечего, тут нет текста запроса, как в случае с SQL.

twin
Здесь должно остаться что-то вроде $f = open_file('dummy.txt', 'r');
И всё.
Остальное уже отвлечение от сути решения.

в самой open_file может сработать бомба throw, except , die() или еще чего-нибудь, и как-то судьбу вытянуть.

Основной код беспокоиться не должон.

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

Действительно, в основном потоке лучше вообще не использовать исключения. Они более необходимы когда происходят вызовы функций, методов, когда основной поток не "контролирует" выполнение кода внутри них. Именно для таких вызовов используются исключения. В блок try {} заносятся вызовы функций, которые могут сгенерировать исключение, в catch(){} мы пишем код, который будет реагировать на них.

Вот решил я пересмотреть свои взгляды на компановку. Прислушаться к советам и не делать диагностики в основном потоке. И тут же этот метод потерпел полное фиаско. Как с эксепшенами, так и с or die.

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

Так что тут скорее всего интереснее использовать компромиссы. В обертках на часто используемые функции юзать debug_backtrace(); и весь остальной джентельменский набор. А с функциями попроще, но требующих логирования не брезговать и в потоке прописать пару строк по моей схеме.

А вот эксепшены тут вообще выпадают. Как громоздкое, тормозное, мутное и вообще ненужное явление.

twin

try
{
    ...
}
catch(Exception $e)
{
    echo $e->getTraceAsString();
}

еще афигенно кохана отдает трейсы, я в своём фрейме тоже подобное реализовал.

Да, со стеком можно помудрить - факт)
Займусь на досуге, спс. Как то я ему особого значения не придавал, зря как видимо.

Вот мой эксепшен (в разработке пока, но все же) с трейсами

Красивенько