При входе, когда ошибка является фатальной?
Может работать пара подзапросов:
SELECT A.Jahr, A.Monat, A.Summe, A.Anzahl, B.AnzahlB
FROM
(SELECT Year(wccrm_orders.ordered_date) as Jahr,
Month(wccrm_orders.ordered_date) as Monat,
round(sum(wccrm_orders.preis)) as Summe,
count(*) as Anzahl
FROM wccrm_orders
GROUP BY
YEAR(wccrm_orders.ordered_date),
MONTH(wccrm_orders.ordered_date)) AS A
LEFT OUTER JOIN
(SELECT Year(wccrm_kunden.anprobe) as Jahr,
Month(wccrm_kunden.anprobe) as Monat,
count(*) as AnzahlB
FROM wccrm_kunden
WHERE wccrm_kunden.status = 1
GROUP BY
YEAR(wccrm_kunden.anprobe),
MONTH(wccrm_kunden.anprobe)) AS B
ON A.Jahr = B.Jahr AND A.Monat = B.Monat
(Извините, у вас нет схемы для этой БД, поэтому в этом коде может быть синтаксическая ошибка (или три!), но, надеюсь, вы поняли идею.)
4 ответа
Я полагаю, что фатальные ошибки, когда Ваше приложение не может больше делать полезной работы. Нефатальные ошибки состоят в том, когда существует проблема, но Ваше приложение может все еще продолжить функционировать, даже на сниженном уровне функциональности или производительности.
Примеры фатальных ошибок включают:
- Исчерпывание дискового пространства на устройстве журналирования и Вы обязаны продолжать регистрироваться.
- Общая сумма убытков сетевого соединения в клиентском приложении.
- Недостающая конфигурационная информация, если никакое значение по умолчанию не может использоваться.
Нефатальные ошибки включали бы:
- сервер А, где единственная сессия перестала работать по некоторым причинам, но можно все еще обслужить другие клиенты.
- случайная ошибка, такая как проигранная сессия, если новая сессия может быть установлена.
- Недостающая конфигурационная информация, если значение по умолчанию может использоваться.
Ошибка является Фатальной, если что-то отсутствует, или ситуация происходит, для которого не может просто продолжиться приложение. Возможными примерами является требуемый config.file отсутствия или когда исключение 'пузыри' и поймано обработчиком необработанных исключений
Сделать этот ответ коротким и сладким, если бы Ваши сбои приложения, я считал бы это фатальным. Если бы Вы не можете соединиться с важным ресурсом, таким как база данных или необходимый сервис, который был бы фатальным. В целом, я сказал бы, что, если бы это мешает Вашему приложению работать правильно и влияет на пользователя, я классифицировал бы его как фатальную ошибку.
, Но самый важный способ классифицировать ошибки должен последовательно следовать за эмпирическим правилом, таким как правило 69 в Стандарты Кодирования C++ :
"Разрабатывают практическую, последовательную, и рациональную политику обработки ошибок рано в дизайне и затем придерживаются его".
Я использовал бы фатальный, если мой следующий шаг - чтобы приложение завершилось, или просто не больше делают последующую работу. Если приложение является частью пакета или существует несколько выполнений процессов, это может быть полезно для трассировки, что произошло.
, Если бы существует шанс восстановления (например, потеря сетевого соединения с повторениями некоторое время) я не использовал бы фатальное.
, Если у меня есть несколько сервисных потоков, активированных основным потоком и одним из них сбои из-за некоторого плохого входа, но приложение может все еще служить новым запросам, я не считаю это фатальным.