привет! как можно игнорить варнинги помимо @my_func() ? так как такая конструкция нехило тормозит код  она делает такое:

можно исправить ошибки и никаких варингов не будет вообще

умно. только это не для кода, а для тестов

не понял. Зачем?
И что собственно нужно сделать?

Добавлено через 57 секунд
Почему не написать свой обработчик ошибок?

Это сообщение отредактировал(а) Fortop - 10.4.2008, 12:13

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

 объясняю
есть код, есть на него тесты с плохими значениями, в случае , например, битого файла (недокаченного etc) код должен без разных ексепшинов просто вернуть false. а варнинги, которые мне об этом сообщают просто-напросто ломают тесты  вот и надо их скипать!  применение @func() юзает ini_set, что есть весьма плохо. ровно в 100 раз быстрее (только что протестила) вот такое:

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

try catch ёпрст!

Он не ловит ошибки, только Exception.
Т.е. нужен еще и свой обработчик ошибок, который будет принудительно кидать Exception

   чуваки, я ж грила - никаких ексепшинов   

во-первых, если твое решение просто не подходит человеку - нефиг гнать на его тесты и приложения.
во-вторых, если ты не понял вопроса также нефиг гнать на вопрошаемого
в-третих, @func использовалось в приложении. и я хочу избегать этот оператор. если не использовать вообще никаких скипов ошибок - валятся тесты. вот я и выдвинула пост дабы узнать мнения по поводу как можно подругому избегать варнингов и прочего подобного.

Добавлено через 2 минуты и 10 секунд
и как вообще могло взбрести в голову, что именно в тестах используется @ ??????

M MoLeX

так, гонор сбавляем... не знаем - не говорим и не советуем...

Добавлено через 1 минуту и 10 секунд
а грубить - эт последние дело, и причем наказуемое

процитированное ниже можно было как-то воспринять иначе?




Я уже не говорю про 

Который сам по себе генерирует ошибку.


Но, разницы для 

33.961764574051с   940000 итераций   0.000036129536780905 среднее время


17.399100780487с   1000000  итераций    0.000017399100780487 среднее время


40.267714977264с   1060000 итераций     0.00003798841035591 среднее время

Практически нет.

А вот, тот замечательный авторский код который тормозил 

завершения его работы я не дождался в течении 10ти минут при 100% загрузке процессора

Сами догадаетесь почему? Или подсказать?

Еще вопросы к непрофессионалам будут?

оно таки завершилось


2811.8342983723с   910000 итераций   0.0030899278004091 среднее время

Это сообщение отредактировал(а) Fortop - 10.4.2008, 17:34

почитай в манах - использование @ интерпретируется как 


и весь вопрос заключался в том - как этого избежать! вот и решение - error_reporting !

Добавлено через 4 минуты и 40 секунд
и в конечном итоге вместо 


имеем


Это сообщение отредактировал(а) MoLeX - 10.4.2008, 18:33

Не соблаговолите ли указать прямой линк на такую трактовку?
Поскольку сам я всегда пользовался http://ua2.php.net/manual/ru/language.oper...rrorcontrol.php

А теперь еще раз и вдумчиво читаем то, что написано ниже.

Для того чтобы не работало в 100 раз медленнее 
Надо


В коде автора


Все еще не понятно?
E_NONE вызывает NOTICE за счет чего и замедляется обработка!
Для просмотра предопределенных констант настоятельно рекомендую пользоваться следующим кодом 




Пожалейте мои мозги и сердце.

alexandra231525480, какими тестами пользуетесь? В UnitTest'ах все отлично работает - если эта ошибка запланированная; для того и придуман assertError.

Это сообщение отредактировал(а) IZ@TOP - 21.4.2008, 18:44

+1   

alexandra231525480, 

зачем? в тестах проблема с производительностью или что? 

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

ps. тема очень похожа на стёб 

У нее проблема с умением писать тесты.

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