весёлый топик сначала человек спрашивал как обойти созданный им же геморрой, а потом стал рьяно доказывать, что этот геморрой - единственно правильное решение. мазохизм какой-то... вот объясни мне, какого лешего функция связи с субд решает когда нужно убить скрипт? а? а в случае неудачного подключения к интернету у тебя комп случаем не выключается?
я обошел то, про что спрашивал, если это про меня. А геморрой будет тому, кто будет ошибки в базе искать.
когда убить скрипт решаю я. сейчас я убиваю скрипт при ошибках в запросах. будет совсем плохой коннект к удаленному серверу - перепишу на другое. попробую еще раз. Запросы у меня выполняются ВСЕГДА, а не по пятницам. Чтобы не происходило. если запрос не выполнился - значит потоп и вторжение марсиан, или совсем упал сервер. У меня нет психологии "запустим и посмотрим, авось заработает". По крайней мере в запросах к базе )) У меня нет ситуаций "неясно, выполнился запрос или нет". он обязательно выполнился. наваливать мусор и смотреть что схавало я не привык.
ищи в мануале - mysql_errno(); Ну а способы проектирования совершенствуются со временем. Поэтому желаю успехов и усердия в чтении ман.
так и не дошло. жаль. разумеется, обработка ошибок бд нужна. но это не означает что надо лепить эти ошибки где попало. При нормальной работе их быть не должно. Мне сейчас нужнее зарубить выполнение вообще при ошибке. В других проектах выполняться должно, но НЕ ТАК, как без ошибки. Поэтому нормальное выполнение должно происходить не вызывая ошибок БД. Люди, которые лепят ошибки в каждом инсерте, учат меня читать маны и проектированию. Ужос.
злой ты. нет бы использовать транзакции, ан-нет, подарил себе и другим геморрой. ты действительно думаешь, что в случае вторжения марсиан лучшее, что можно сделать - это вывести пользователю чистую страницу, а не сообщение о временных неполадках и предложением посетить пока другие работающие разделы сайта?
размазанные на несколько модулей? это зависит от назначения. но в любом случае не надо городить уникальные обработчики ошибок на каждый запрос. и ты прицепился к постороннему куску кода, приведенному для примера. при любом раскладе не надо писать инсерт, вызывающий ошибку при нормальной работе. тогда и сообщение о временных неполадках можно будет вызывать.
такое утвержение говорит о непонимании того, как нужно строить бизнес-логику приложения. Имеено для того, что бы ничего не «размазывать» логику от представления и отделяют. И, да, транзакции для этого как раз и нужны.
armadillo, а ты пиши инсерты которые не вызывают ошибок. а касательно убивания скрипта я с тобой не согласен. вот полезу я регится, заполню форму и отправлю... и буду созирцать белый экран из-за того что мои данные не понравились твоему инсерту и ты задавил скрипт... намного приятнее будет не вспоминать твих родственников если будет возвращено хотя бы "идите нахрен, у нас мускул накрылся тазом" ошибки на то и принято показывать чтобы найти подход при котором их не будет... die в этом случае самое отвратительное что можно придумать Опытные и уважаемые люди между прочим...
то есть ты гарантируешь, что написанный тобой код никогда не выдаст ошибку при обращении к БД? ты неимоверно крут!
Запрос может вызвать ошибку не по вине программиста, а по вине сервера, мало ли что ему там всбрело в "моск". Пример с регистрацией не очень удачный, т.к. в теории нормально написанный код сам по себе ошибки не вызовет и опять таки переходим к первому высказыванию. ИМХО
в данном конкретном случае у меня все локально и мне важнее, чтобы юзер сам сразу прибежал ко мне с криком "все не работает!", чем потом выяснять какие данные криво введены пока я в отпуске и что там было. а находить в принципе не работающие куски чужого кода, потому что все ошибки подавлялись, мне уже порядком надоело. и апдейтить базу после этого по принципу "сделаем вид что все было вот так" тоже. да, после отладки. дело не в крутости, а в психологии. я до www много лет занимался локальными базами, где ошибка в данных стоила в лучшем случае части чьей-то зарплаты. до сих пор тяжело воспринимать отношение большинства "ввв-кодеров"
я до сих пор занимаюсь «локальными» базами, и ошибка в данных стоит рабочего места и судебного разбирательства.
Входящие данные надо ВСЕГДА проверять до того, как они добавляються в базу. До момента вставки/обновления записи в базе данных должно доходить только тогда, когда данные 100% правильны. Если в результате выполнения запроса может возникнуть ошибка, значит есть глюки в проверяющем коде выше и его надо править. Если данные ошибочны, я просто перенаправлю пользователя на форму с сохранением им введённых данных и вывожу текст ошибки, мол исправте то-то. Проблем с судебными разбирательствами и потерей рабочего места не возникало Горбунов Олег
Ошибку надо обрабатывать, это очевидно. Но то, что тут первым делом стали советовать "а ты напиши с ошибкой" - вызывает ужас.
ужас - это необработанная ошибка. а ожидаемая ошибка - ошибкой как таковой и не является. и твой die() ничем не лучше не обработанного fatal error. банальный пример: пишем веб-сервис, который должен возвращать XML. с твоим die() он либо ничего не вернёт, либо вернёт не XML. ps: а использовать пользователей для уведомления админа о неполадках - это, конечно, неимоверно круто у тебя сайт из-за неполадок с БД не доступен совершенно - пользователям, банально, негде посмотреть твои координаты.
хватит переругиваться по пустому )) лучше обсудим пример с первой страницы. если вместо сделать PHP: 'insert into online set user_id='.(int)$someUserId.', last_activity=now(), field1='.$value1.',... on duplicate key update last_activity=now()' чем оно будет плохо?