Разницы нет, пока не надо задумываться об этом при интеропе. Стандартом де-факто является интероп с Си. А там нумерация с 0, потому что это следует из арифметики указателей.
Исключения должны подниматься там, где корректная работа в сложившейся программной среде не представляется возможным, а обрабатываться они должны там, где становится возможным восстановиться после исключения.
Пример: если пользователь запросил содержимое файла, которое недоступно, то в момент попытки открытия или чтения может быть поднято исключение, если файла нету или он недоступен по какой-то причина. Обрабатываться такая ситуация должна в точке, где знаний о том, зачем файл был запрошен, достаточно, чтобы выйти из ситуации. Например, если файл был нужен чтобы прочитать настройки, то отсутствие такового файла может означать, что настроек ещё нету и надо вернуть настройки по умолчанию.
Ну или не восстановиться, что укажет на баг. Только аккуратно, с логированием, чтобы это было не просто падение, а что-то осмысленное. Но потом обязательно прекратить работу, чтобы не запороть пользовательские данные.
Исключения не являются частью контракта метода. Более того, разные реализации одной и той же абстракции могут иметь разные наборы поднимаемых исключений - что с этим делать прикажете? Как только исключения становятся частью полиморфного контракта - он больше не полиморфный.
Для таких ситуаций и есть иерархия исключений с корневым типом на все оставшиеся случаи жизни.
Ничем не плох, просто специализированное средство там, где надо. А там, где не надо (как в статье) - это дурно пахнущий код или неудачный выбор инструментария под задачу.
А теперь поменяйте длину массива на что-то, не кратное размеру регистра, и посмотрите на кодген: появится обработка хвоста. Но именно знание длины массива позволило удалить этот хвост.
А точно это не ошибка копипасты и теперь мы замели под ковёр пропуск какой-то важной опции при проверке? (хотя наверное неважной, если до сих пор не было замечено)
Ещё надо трекать ссылки на другие объекты. Возможно, циклические.
Разницы нет, пока не надо задумываться об этом при интеропе. Стандартом де-факто является интероп с Си. А там нумерация с 0, потому что это следует из арифметики указателей.
ОНО ЖЕ ПРОКРИЧАЛО, что дальше больше не safe, но это Вас не остановило.
Когда 17-18 лет назад выбирал скриптовый язык в проект, предпочтение было отдано именно Squirrel-у. Lua и Python рассматривались тоже, но проиграли.
Вообще говоря обязан.
Исключения должны подниматься там, где корректная работа в сложившейся программной среде не представляется возможным, а обрабатываться они должны там, где становится возможным восстановиться после исключения.
Пример: если пользователь запросил содержимое файла, которое недоступно, то в момент попытки открытия или чтения может быть поднято исключение, если файла нету или он недоступен по какой-то причина. Обрабатываться такая ситуация должна в точке, где знаний о том, зачем файл был запрошен, достаточно, чтобы выйти из ситуации. Например, если файл был нужен чтобы прочитать настройки, то отсутствие такового файла может означать, что настроек ещё нету и надо вернуть настройки по умолчанию.
Ну или не восстановиться, что укажет на баг. Только аккуратно, с логированием, чтобы это было не просто падение, а что-то осмысленное. Но потом обязательно прекратить работу, чтобы не запороть пользовательские данные.
Исключения не являются частью контракта метода. Более того, разные реализации одной и той же абстракции могут иметь разные наборы поднимаемых исключений - что с этим делать прикажете? Как только исключения становятся частью полиморфного контракта - он больше не полиморфный.
Для таких ситуаций и есть иерархия исключений с корневым типом на все оставшиеся случаи жизни.
И вообще: https://devblogs.microsoft.com/dotnet/await-anything/
В греческом угаре unsafe нужен исключительно для указателя в делегате, а не для греков.
Дичь нулевая - называть дичью то, чего автор либо не понимает, либо тупо стебётся на серьёзных щщях.
PS: третье -- красиво. Остальное - смех гопников над прохожими.
И опять нарываемся на квест "ублажи ментально рандомную девочку - стража спокойствия технаря".
Вторым был LoCode/NoCode подход. LLM - это уже третий.
Можно сэкономить время, отбросив 90% случайных анкет со словами "Не люблю неудачников".
*Примечание: копировать надо исходник из ответа, а не из вопроса
-- Мы тут увидели Ваше резюме и хотим позвать Вас на собеседование!
-- А Чем занимается ваша компания?
Ничем не плох, просто специализированное средство там, где надо. А там, где не надо (как в статье) - это дурно пахнущий код или неудачный выбор инструментария под задачу.
Нафига было писать на C#, чтобы потом скатиться в p/invoke?
Контрольная сумма - только последняя цифра.
А ещё бесит, когда тебе нужна информация с какого-нибудь сайта, но тебя там заставляют зарегистрироваться и требуют ввода сложного пароля.
Вот тут реально пофиг, что пароль будет 111
А теперь поменяйте длину массива на что-то, не кратное размеру регистра, и посмотрите на кодген: появится обработка хвоста. Но именно знание длины массива позволило удалить этот хвост.
Рефакторинг без контекста - корень всех бед.
А точно это не ошибка копипасты и теперь мы замели под ковёр пропуск какой-то важной опции при проверке? (хотя наверное неважной, если до сих пор не было замечено)