Это баг. И заключается он в том, что в ТЗ четко прописано что значение не должно ровняться нулю, а программа все-равно 0 пропускает. Значит где-то баг в фильтрации значений.

То что где-то есть баг - согласен.
Не согласен с тем, что краш по делению на ноль, в этих обстоятельствах - баг. Баг там, где появился этот ноль, который не должен был появиться. Это мог быть внеший по отношению к нам программный модуль. И полный и категоричный отказ промолачивать заведомые гoвноданные, в ряде случаев - намного лучше, чем аккуратное заметение под коврик ситуации, которой не должно возникать в принципе.

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

Это сообщение отредактировал(а) Zloxa - 4.10.2013, 16:33

Вообще-то в английском есть и "error" и "mistake" и уже IT-жаргонный "bug" и, возможно сюда и "failure" с "fault" впишется. Но вот то что слова "баг" в русском изначально не было - это верно  Но теперь-то уже есть, так что отклоняется! 

Пока читал, вспомнил про интересные эффекты в играх. Например, если в самом первом "Sonic The Hedgehog" на некоторых уровнях вставать на определенный пиксель на движущейся платформе, то наш ёжик проваливается под платформу, исчезает с глаз, а затем происходит что-то уж совсем странное: камера переезжает к концу уровня, причем даже соника не видно, он возникает только в конце. Чувствую что отхожу от темы, но вот что это? Есть ещё новомодное слово "глитч", но тут оно наверное не подходит. Тут явно баг. Даже непонятно, разработчики сделали это специально, или это какой-то не предусмотренный эффект? Кому интересно, можно посмотреть здесь (на 9:00 примерно такой же эффект): ссылка на момент с багом в прохождении Sonic на YouTube

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

Это сообщение отредактировал(а) ne_tru_e - 4.10.2013, 22:53

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

Ну, это не ко мне вопрос. Заимствований из других языков уже давно много, и с этим ничего нельзя поделать. В русском языке есть ещё и "глюк", можно пользоваться вместо бага.

Что значит "Вполне может быть"? Ты сомневаешься что ли?  По-моему и ежу понятно, что единственный способ получить такую информацию - надиагностировать ее. Возможности диагностики - безграничны. Даже не сомневайся в этом  

я различаю ошибку (error) от оплошности (mistake):

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

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

1) в расценках решения:

• выявленная оплошность (обычно) дешева в починке, ее нередко замечают во время code review, или быстрого взгляда на код еще раз, эта сфера (теоритически) должна покрываться полноценным процессом разработки (т.е. контролем качества)
• выявленная ошибка нередко заставляет пересмотреть реализацию компонента или даже всю архитектуру. Tут yж никакой процесс не поможет, ошибкам легче пробираться в выпущенный продукт в полном "прокате", т.е. даже если есть команда QA, т.к. нередко им трудно отречься от общения с разрабами и "проникновения" веверным подходом к решению задачи.

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



Это сообщение отредактировал(а) bilbobagginz - 5.10.2013, 20:05

ne_tru_e, а Вы различаете дом и home, Землю от    
earth отличаете, мышь от mouse?

Добавлено через 6 минут и 7 секунд
вот как раз от кривого алгоритма неожиданный эффект и проистекает, ничего мистического в машинах нет, а на твои речи даже Билл хором с римским папой заорёт: "Ересь". И первый попавшийся иезуит им поддакнет и скажет, что тебе повезло, что живёшь среди цивилизованных людей, благодаря чему инквизитор с факелом по близости не околачивается.

Это сообщение отредактировал(а) ТарасАтавин - 8.10.2013, 06:28

в контексте багофичи встаёт вопрос об оценке корректности любой работы любого алгоритма. Если ты пишешь модель электрометаллургического агрегата для целей САУ, то любая неадекватность модели есть баг, так как из-за него не правильным будет уже управление, в итоге в лучшем случае сварят дряную сталь, а потом сделанную из неё дверцу машины можно будет гнуть об локоть, а лист толщиной 20 мм будет коловоротом за 30 с дырявиться сверлом диаметром 40 мм, что не получается даже при замене листа кривостали доской из любой, сколь угодно мягкой породы дерева. Но если ты модель того же агрегата пишешь для игры, то можешь заявить, что в игре иная физика, по которой лапласиан потенциала в проводнике не равен нулю и объявить то же самое поведение алгоритма фичей. Если статья писана для любителей поиска очепяток и даже грубых ошибок, то слова "отака" - фича, а если для серьёзных читателей - ошибка.

Добавлено @ 06:56
В программировании в частности и в IT вообще возможны лишь две ошибки, не являющееся багами:
1. Ошибка в символе, или строке, предназначенной для вывода человеку (на дисплей, на принтер, на телетайп...): будучи ошибкой языка общения, а не программирования, такая ошибка не затрагивает алгоритм. Например, если пункт меню на экране будет назван не "Edit", а "Adit", или "Edeet", но в оконной процедуре идентифицирован правильно, то это ошибка с точки зрения английского языка, но не баг с точки зрения языка c++. Любая ошибка, являющаяся таковой с точки зрения языка программирования, есть баг и всякий баг есть ошибка.
2. Синтаксическая ошибка, на столько грубая, что компилятор её вообще не пропустит. До какого либо поведения алгоритма такая ошибка просто не дойдёт.

Это сообщение отредактировал(а) ТарасАтавин - 8.10.2013, 07:00

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

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

Добавлено @ 09:48
Например, если ты положишь PI=4, а во все формулы заложишь корректирующий коэффициент: l=3.1415926535897932384626433832795*PIr/2, s=3.1415926535897932384626433832795*PIr^2/4..., то такое значение PI ошибкой не будет, так как данные не обязаны соответствовать тому, что понимается под именованными константами в математике, а при таком PI 3.1415926535897932384626433832795*PI/4 равно обычному PI. 

Это сообщение отредактировал(а) ТарасАтавин - 8.10.2013, 09:49

Мне одному интересно, он это по памяти написал?   

Poseidon, не надо преувеличивать.

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

Это сообщение отредактировал(а) Zloxa - 8.10.2013, 10:06

Нет. Требования формулируются для того, что хоть на что то влияет, а  - это константа-тёзка, если гарантированы правильные значения площади круга, длины окружности, площади сферы и объёма шара, то это не ошибка. А если ты декларируешь , но используешь не правильную формулу l=PI*r, то вот это и есть ошибка, при такой формуле правильное PI равно 6.283185307179586476925286766559. Если задача не число PI хранить в качестве справочного данного, а длину окружности вычислить, то в требования закладывается её правильное отношение к диаметру, а назовёшь ты PI это отношение, отношение длины окружности к радиусу, площади круга к диаметру, или что угодно ещё, значения не имеет. Главное гарантировать правильные результаты на выводе при любом вводе, в том числе, при обмене с другими программами, а как ты переиначишь внутри имена констант - твоё личное дело. Можешь вообще корнем квадратным назвать куб, а кубом корень квадратный, но и применять их наоборот и ошибкой это тоже не будет.

Это сообщение отредактировал(а) ТарасАтавин - 8.10.2013, 10:14