поддерживаю. меня тоже заинтиговало почему не делать???

если чисто ради супер пупер парапупер кодинга, аля возвращать всегда код, притом не числом а константой, и проверки константой то это ладно, но подзреваю что сдесь ещо какаято причина???

ответь пожалуста, почему не делать так?

Програмёр,

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

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

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

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

ЗЫ
в твоём случае всётаки лучше код возврата - мне так кажеться.

ScareCrowавторА теперь главный вопрос, а кто сказал что "error1" или "error2" являются "неправильными" ответами? Вполне себе нормальная ситуация, человек проверяет состояние некоторого компонента (например некой модели) и смотрит:

а теперь посмотрите как это у нормальных людей сделанно.

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

а если в зенд, так там неделями можно смотреть пока поймёшь их концепцию...

ПрограмёрИзопропилПрограмёр,

А вместо пачки параметров единственный объект "контекст" никак не передать?

неее ))) это не по условиям... у нас нету объектов :) А если объект = ассоциативный массив, то в чём разница? Получится то же самое, просто в EngineWrite сейчас передаётся несколько десятков аргументов явно, а в предложенном варианте они будут передаваться неявно (что ещё неудобнее).

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

ТАК

ПРОГРАММЕР
1)ты не понял намёк, ты написал про структурное - как антоним ооп, а тебя протролили..ведь структурное, это как бы антоним функциональному (это не там где функции и процедуры). ещо есть процедурное, которое ты имел ввиду скорей всего, но сказал структурное.

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

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

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

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

это естественный процесс вообщето. точно такиеже процесы но вдругой интерпритации
1)похудание
2)борьба с курением, алкоголизмом
3)разные системы личностного роста и повышения эффективности
4)среди менеджеров тоже есть тонна теорий про то как эефективно управлять...

и что интересно ни одна школа менеджмента не может похвастаться(вот великий менеджер стал виликим, ибо придерживался нашей школы)

или доктор по похуданию тем что у него худают все и всегда

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

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

alex564657498765453,

СОРИ пропустил концовку мысли

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