Как программный продукт должен обрабатывать нарушение доступа - PullRequest
0 голосов
/ 30 апреля 2010

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

Наш ответ - поймать ошибку и продолжить работу.

У меня вопрос, это ответственный подход? Ответственно ли за то, чтобы приложение оставалось в живых, когда оно так катастрофически отказало? Будет ли более ответственным предупредить пользователя и умереть?

Edit:
Один из аргументов в пользу того, чтобы исключение не обрабатывалось, заключается в том, что нарушение прав доступа показывает, что программе было запрещено причинять вред, и, вероятно, она также не сделала ничего. Я не уверен, что куплю это. Есть ли мнения по этому поводу?

Ответы [ 2 ]

3 голосов
/ 30 апреля 2010

Я с Игнасио: необходимо получить исправление для этого компилятора КАК МОЖНО СКОРЕЕ, или, если такое исправление не ожидается, для перехода с корабля. Естественно, могут быть препятствия для этого, и я предполагаю, что вы ищете краткосрочное решение на пути к достижению этой цели. : -)

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

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

2 голосов
/ 30 апреля 2010

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

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

Как вы думаете, клиент знает о проблеме?

...