Форум PHP

Здравствуйте
для каких целей используется throw ?

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

а что через if {} ....
не подходит?
походу слишком все относительно

if тут вообще не причем, вы путаете твёрдое с мягким. гляньте в мануале описание exception
http://php.net/manual/ru/language.exceptions.php

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

<?php function inverse($x) {     if ($x == 0) {        return  'Деление на ноль.';        // throw new Exception('Деление на ноль.');     }     else return 1/$x; } echo inverse(5) . "<br />"; echo inverse(0) . "<br />"; //try { ////    echo inverse(5) . "\n"; //    echo inverse(0) . "\n"; //} catch (Exception $e) { //    echo 'Выброшено исключение: ',  $e->getMessage(), "\n"; //} // Продолжение выполнения echo "Hello World\n"; ?>

результат тот же.

конечно, а еще результат тот же, если просто написать:
echo '0.2<br/>Деление на ноль.<br/>Hello World';
или echo implode('<br/>', array(0.2, 'Деление на ноль.', 'Hello World'));
и еще сто вариантов как добиться того же результата.
дело не в результате. это ооп, здесь не только важен сам результат, но и то, как его добиваться. в чем смысл я написал в самом первом посте. вижу что у вас всё совсем туго, поэтому обращайтесь к самым основам. просто так на форуме вряд ли получится охватить всё
p.s else кстати не нужен, подпортили только пример. основы языка тоже желательно подучить

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

про ваш первый пост

"обычно применяется в ооп ...... то в таком случае удобнее всего выбросить исключение"

знаете, кашу есть удобнее всего ложкой, только вот ее и вилкой едят.
если это ваше "пояснение" то извините.....

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

PS: а то что там else можете считать опечаткой, по привычке.
еще расскажите что сие нагрузило интерпретатор и вызвало у него когнитивный диссонанс.....
а все эти try catch это must have.
а если немного подумать, то ведь ясно, что пример не отображает нужды применения сего подхода, а лишь демонстрирует суть.

а я то всего хотел понять нафига попу лопата....

Дело даже не в ООП как таковом, а в самом понимании "исключительных ситуаций", которое есть во всех языках программирования, и которые могут быть синхронные, возникающие в определённых и известных точках программы, где вы пытаетесь "описать крах как if...", а могут быть асинхронные, возникающие в любой момент времени и независящие от конкретной инструкции программы, и в данном случае if тем более бесполезен.

чтобы понять, "нафига попу лопата" необходимо:
1) изучить полностью встроенный в PHP класс Exception, немного дальше начального примера, посмотреть что он из себя представляет и какие в нём встроенные возможности (а именно getTrace, getFile, getCode и т.д)
2) еще раз перечитать внимательно мой первый пост. не между строк, а всё вместе.
и еще раз, исключения нужно бросать когда в алгоритме всё пошло не так, как изначально задумывалось, т.е когда мы сталкиваемся с ситуацией, когда дальнейшая работа скрипта невозможна или не имеет смысла. ваш return ведет себя совсем не так, он всего лишь является точкой выхода их метода

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

>а все эти try catch это must have.
да, когда речь идёт об ооп. и у меня такое чувство, что вы с ним не знакомы

если ваше - его используют в.. при... это круто... это ооп.... объясняет все, то флаг вам в ... куда захотите
более того ссылка на пхп.нет так же не раскрывает сути, а лишь приводит пример использования
вы определитесь мне читать что по ссылке или читать еще где?
к сожалению вы даже реального примера не соизволили привести, кроме голословных - "я нуб"
вы со своим ооп просто параноик, у верен "привет мир!" у вас тоже реализовано через класс, как ЧСВ уже зашкалило?

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

спасибо конфёрму он и то больше подкинул зацепок чего посмотреть.
спасибо за диспут.

чтобы конкретно понять всю прелесть этого подхода, нужен целый проект. тогда будут видны все преимущества, т.к в крупной системе это нагляднее всего, и обработка исключений в таком случае не только даёт понять, где именно произошла ошибка (а так же её код, текст, файл, номер строки), но и отследить всю цепочку вызовов к ней, все параметры, которые получают методы и так далее. и я со своим ооп не параноик, просто я думаю, эта тема не может существовать отдельно от ооп.
вот наглядно, что лично мне даёт обработка исключений (см аттач)
вся эта цепочка вызовов отслеживается именно благодаря встроенному классу Exception. это наглядно и удобно. конечно, если брать самые простые примеры из мануала, да еще и не зная, что с чем едят, это может быть достаточно сложно. но и здесь всего лишь форум, и вряд ли кто-то будет сидеть и писать вам пример строк на 100 кода, чтобы всё это было очевидно.
поэтому я просто советую подучить нормально теорию, желательно по свежим книгам + в интернете хватает нормальных статей по этой тематике, вот эта хотя бы http://habrahabr.ru/post/58687/
в конце концов, на то, чтобы почитать лурк, у вас было время, значит найдётся и на это.
когда более-менее разберетесь, сядьте и напишите сами свою мини-систему, хотя бы несколько полноценных классов например для работы с базой данных, или с различными конфигурационными файлами и т.п и думаю придёт просветление.

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

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