код в тему ... помнится кто-то просил примеры приводить  , это раз
во-вторых, что-то мне кажется, что ядро Linux никогда не будет поддерживать модули на Python   в силу объективных обстоятельств, потому примера я не дождусь   

скажи спасибо slav0nic   

ps.    закрывайте тему   

Это сообщение отредактировал(а) MAKCim - 15.1.2007, 16:44

ну я как бы ответил тем, кто говорил что питон плохо) и на нём многие вещи нереалиуземы
просить написать модуль под ядро, равносильно если я попрошу написать игру для моего мобильника на делфи), кстати... на питоне можно В)

ps: закрывайте тему =)  
и удаляйте ветку делфи)))
и подфорум "красная книга" не соответсвует содержанию

 Кстати да: один язык из красной книги популярнее, чем делфи, в 5 с лишним раз(по миру, а не по России)

Предлагаю поменять местами эти форумы, т.е. один вынести из красной книги, а другой занести!

английский язык, что ли?

Несколько Оберон-ОС и MS Singularity имеют в своей основе этот же принцип: защита данных на уровне безопасных ЯП, без аппаратных средств. Какое-то ограниченное применение этот подход найдёт.

Аппаратно быстрее и надежнее (какими бы не надежными были ЯП) (имхо)

skyboy, питон.
примерно 20 страниц назад я статистику уже приводил.

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

например в джаве:

да, да. в С++ тоже есть спецификаторы исключений. Они правда имеют немного другое поведение нежели в java и не очень хорошо реализованы, но всё же есть;) А в Delphi?

javastic, 

я в яве ноль , так что на пальцах объясни что это делает

  ИМХО маразм генерить ошибку, там где она только может возникнуть и лепить без спроса код. В перехвате ошибок я не силен, но знаю, что имеется несколько альтернатив обработки исключений. Пока идет дебаг версия сообщения об ошибках только на руку, помогают определить узкие места, потом отключил и ловишь там где нужно, обрабатывая каждый тип исключения отдельно или универсальный обработчик. В чем прелесть? В том что тебе навязывают обработку везде, где надо и где не надо, при этом оставляя только одну альтернативу для обработки ошибок? 

Унифицированный стандартный подход для обработки ошибок
Делает код более "стандартным" и надежным
Вы, дельфисты, сами же ЗА надежность и прямолинейность кода   Или нет?   

почти тоже самое что в С++

Romikgy, представь что ты пишешь код как в нашем примере с файлом. В своём методе используешь к примеру уже готовый API метод writeBin(...) в котором нет исключения на то что файл может быть заблокирован ОС, но есть общее исключение того что запись не произвелась. Ты создаешь своё исключение например FileBlockedException и вызываешь его. Также говоришь методу что он следует исключению void method() throws FileBlockedException {....}. Всё, новый метод в твоём классе описан. Представь что 
Alexeis решил воспользоваться этим классом и непосредственно методом method() он делает экземпляр класса, и в своём коде использует твой метод. Пытается компилить, а не получается, потому что компилятор говорит: сделай проверку на этот метод, потому что он может вызвать ошибку. 
Alexeis'а не волнует как реализован метод method(), но его код будет подстрахован от возможной ошибки
и он пишет 


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

---



А вот это ты просто не понимаешь где такая фича может пригодиться. Поройся в Делфи там наверняка тоже есть что-то типа Raise Error'a. 

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

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