Я бы еще добавил рекомендацию написать для приложения обработчик Unhandled Exceptions, который обязательно должен вести лог необработанных исключений. Часто об этом забывают поначалу.
Если даже и нет, Вы можете создать свой класс, наследованный от Exception, который будет в конструкторе принимать вложенное исключение.
Мне вот больше интересно, а в PHP можно получить стектрейс исключения?
//
(я тоже .NET разработчик)
На мой взгляд, паскаль — один из самых лучших инструментов для становления начинающего разработчика. Он прививает четкость мышления, азы алгоритмизации, построения структурированного кода и работы с вводом-выводом. Мне кажется, лучшего, чем турбо паскаль для начала — не найти.
Из личного опыта — сначала в школе изучал именно паскаль, потом перешел на С/С++, когда начал писать программы для Windows (десктоп приложения) — это мне дало базовые знания системного программирования, затем изучал ассемблер, форматы исполняемых файлов (мне кажется, это очень важно для понимания, что вообще происходит в системе). Потом пробовал дельфи, параллельно пробовал веб-программирование на PHP, и после этих экспериментов остановился на платформе .NET, на чем в данный момент и сконцентрирован по большей части. Сейчас для общего развития интересуюсь разработкой на Java (J2EE).
//
В принципе, свой путь я считаю началом пути по правильному для моих интересов направлению. Если я о чем-то жалею сейчас, так это об относительно небольшой практике.
Спасибо, как раз не хватает материала, связанного с реализацией обращений из unmanaged кода к managed-подпрограммам. Обратный механизм достаточно прозрачен, и почитать есть что, а вот это как раз то, что нужно! Присоединяюсь ко всем, кому понравилось. Продолжайте, буду читать с удовольствием.
Для обычных пользователей (не сисадминов и не разработчиков) GUI действительно предпочтительнее CLI в подавляющем большинстве случаев. Поэтому, в такого рода заявлениях нет ничего удивительного. Все равно бухгалтерам в сто раз удобнее работать с помощью несложных тыкательных интерфейсов, нежели соображать, какую команду ввести в консоль. А для специализированных задач CLI необходим как намного более гибкий (а вместе с тем, и сложный) инструмент. И, мне кажется, что здесь нет никакого противоречия.
имхо, еще лучше в коде Dispose() класса-наследника заворачивать полезный код в блок try-finally.
Dispose(bool isDisposing) {
try {
// Disposing derived class
} finally {
base.Dispose(isDisposing);
}
}
ну, может быть, вы и правы, с башем я не работал, но слышал отзывы.
однако, мне все-таки кажется, что с объектной моделью работать удобнее, нежели с текстом. во всяком случае, олдскульные методы не теряют актуальности (т.к. ToString всегда в кармане :) ).
проставлять флаг disposed = true лучше перед основным кодом освобождения ресурсов, иначе может быть проблема с многопоточным кодом. а финалайзеры — особая тема, не всегда следует их реализовывать по нескольким причинам. во-первых, существуют классы, которые требуют детерминированного уничтожения (например, используют другие managed-ресурсы, которые должны быть освобождены). в этом случае финалайзер не будет выполнять полезной работы и будет только мешать, создавая иллюзию нормальной работы и замедляя работу приложения (финалайзеры требуют особого обращения со стороны среды выполнения CLR .NET). кстати, в таких случаях в финалайзер можно засунуть метод оповещения о том, что объект не был освобожден принудительно, таким образом сигнализируя об утечке памяти / ресурсов. и этим мы элегантно превращаем «плохой» финалайзер в «хороший» и полезный. подробнее об этом я тоже планирую написать отдельную статью.
//
а вообще, ничего, спасибо вам за труд.
Почему это было бы лучшим решением, на ваш взгляд?
Мне кажется, что концепция PowerShell выгодно отличается от basha хотя бы тем, что она — новое изобретение, а не ремикс давно известных. Кстати, имхо, на bash'e было бы сложно сделать некоторые вещи из тех, о которых написано в упомянутой книге.
Да, отступы на анонимных делегатах и type-инициалайзеров мне тоже не нравятся. Но это настраивается. Я обычно при миграции с версии на версию с собой таскаю XML-конфиг с настройками кодстайла, там большинство настроек прописано (кроме настроек Hint'ов).
Ставил бету — иногда выкидывала Unhandled exceptions, 4.1 была ощутимо стабильнее.
Будем надеяться, что теперь и 4.5 стала такой же стабильной, как и предшественница.
Мне вот больше интересно, а в PHP можно получить стектрейс исключения?
//
(я тоже .NET разработчик)
Из личного опыта — сначала в школе изучал именно паскаль, потом перешел на С/С++, когда начал писать программы для Windows (десктоп приложения) — это мне дало базовые знания системного программирования, затем изучал ассемблер, форматы исполняемых файлов (мне кажется, это очень важно для понимания, что вообще происходит в системе). Потом пробовал дельфи, параллельно пробовал веб-программирование на PHP, и после этих экспериментов остановился на платформе .NET, на чем в данный момент и сконцентрирован по большей части. Сейчас для общего развития интересуюсь разработкой на Java (J2EE).
//
В принципе, свой путь я считаю началом пути по правильному для моих интересов направлению. Если я о чем-то жалею сейчас, так это об относительно небольшой практике.
сам намучался на работе )
Dispose(bool isDisposing) {
try {
// Disposing derived class
} finally {
base.Dispose(isDisposing);
}
}
однако, мне все-таки кажется, что с объектной моделью работать удобнее, нежели с текстом. во всяком случае, олдскульные методы не теряют актуальности (т.к. ToString всегда в кармане :) ).
//
а вообще, ничего, спасибо вам за труд.
Мне кажется, что концепция PowerShell выгодно отличается от basha хотя бы тем, что она — новое изобретение, а не ремикс давно известных. Кстати, имхо, на bash'e было бы сложно сделать некоторые вещи из тех, о которых написано в упомянутой книге.
Будем надеяться, что теперь и 4.5 стала такой же стабильной, как и предшественница.