Аннотация:
Framework Design Guidelines, Second Edition, teaches developers the best practices for designing reusable libraries for the Microsoft .NET Framework. Expanded and updated for .NET 3.5, this book new edition focuses on the design issues that directly affect the programmability of a class library, specifically its publicly accessible APIs.
Здравствуйте, _FRED_, Вы писали:
_FR>А не сложно рассказать про отличия от первого издания?
Ну, первое издание я не читал. Но сейчас нарыл содержание первого издания и сравнил его с содержанием второго издания. Вот что вышло.
Добавлены следующие разделы:
5.6 Extention Methods
8.4 DateTime and DateTimeOffset
8.8 Nullable<T>
9.2 AsyncPattern добавлены подразделы по EventBased Async Pattern
9.3 Dependency Properties
9.6 LINQ Support
9.11 XAML Readable Types
Содержание по ключевым пунктам осталось практически не изменным. Но книга выросла примерно на сотню страниц. Например, глава по исключениям увеличилась с 28 до 33 страниц. Т.е. либо издатель выбрал более крупный шрифт либо, что более вероятно, материал книги переработан и расширен.
После прочтения книги особенно воодушевляют беседы, подобные той, что происходят сейчас в соседней ветке здесь
, т.к. глава по исключениям в этой книге особенно понравилась. Все же попытка защититься от любого исключения больше смахивает на параною, а не нормальный способ обработки ошибок.
Я ни в какой другой книге не встречал такого классного описания проблемы обработки ошибок. Вот, не поленился перебить кусок книги:
You should first decide whether the error condition represents a usage error or an execution error.
A usage error represents an incorrectly written program and is something that can be avoided by changing the code that calls your API. There is no reason to programmatically handle usage errors; instead the calling code should be changed. For example, if a routine gets into an error state when a null is passed as one of its arguments (an error condition usually represented by an ArgumentNullException), the calling code can be modified to ensure that null is never passed. In other words, usage errors can be fixed at compile-time, and the developer can ensure that they never occur at runtime.
An execution error is something that cannot be completely avoided by writing "better" code. For example, File.Open throws FileNotFoundException when it tries to open a file that does not exist. Even if the caller of the API checks whether the file exists before calling File.Open, the file can get deleted or corrupted between the call to File.Exists and the call to File.Open.
Execution errors need to be futher divided into two groups: program errors and system failures.
A program error is an execution error that can be handled programmatically. For example, if File.Open throws FileNotFoundException, the calling ode can catch the exception and handle it by creating a new file. This is in contrast to the usage error example described earlier where you whould never write code that first passes an argument to a method, catches the NullArgumentException, and in the handler calls the method with a non-null argument.
A system failure is an execution error that cannot be handled programmatically. For example, you really cannot handle an out-of-memory exception resulting from the Just-in-Time (JIT) compiler running out of memory.
Здравствуйте, SergeyT., Вы писали:
ST>Только судя по качеству книг, изданных издательством Вильямс в последнее время, не известно, это хорошая новость или нет
Судя по переводу названия, уже известно
«Принципы разработки инфраструктуры проектирования: соглашения, идиомы и шаблоны для повторного использования библиотек .NET»
Здравствуйте, jedi, Вы писали:
J>Очевидно, что здесь идет речь о ExecutionEngineException (с сообщением "out of memory"), а не об OutOfMemoryException. JIT compiler не должен бросать OutOfMemoryException, если он это делает, это мега-глупость.
At one end of the spectrum, an OutOfMemoryException could be the result of a failure to obtain 12 bytes for implicitly autoboxing, or a failure to JIT some code that is required for critical backout. These cases are catastrophic failures and ideally would result in termination of the process. At the other end of the spectrum, an OutOfMemoryException could be the result of a thread asking for a 1 GB byte array. The fact that we failed this allocation attempt has no impact on the consistency and viability of the rest of the process.
The sad fact is that CRL 2.0 cannot distinguish among any points on this spectrum. In most managed processes, all OutOfMemoryExceptions are considered equivalent and they all result in a managed exception being propagated up the thread. However, you cannot depend on your backout code being executed, because we might fail to JIT some of your backout methods, or we might fail to execute static constructors required for backout.
Also, keep in mind that all other exceptions can get folded into an OutOfMemoryException if there isn't enough memory to instantiate those other exception objects. Also, we will give you a unique OutOfMemoryException with its own stack trace if we can. But if we are tight enough on memory, you will share an uninteresting global instance with everyone else in the process.
My best recommendation is that you treat OutOfMemoryException like any other application exception. You make your best attempts to handle it and ramain consistent. In the future, I hope the CLR can do a better job of distinguishing catastrophic OOM from the 1 GB byte array case. If so, we might provoke termination of the process for the catastrophic cases, leaving the application to deal with the less risky ones. By threating all OOM cases as the less risky ones, you are preparing for that day.
Christopher Brumme
P.S. Это все из той же Framework Design Guidelines.
Здравствуйте, jedi, Вы писали:
J>Один-в-один то, что я написал в той ветке. Пытаемся обработать, не получилось — извините.
Не совсем. Брюмме советует обрабатывать "лёгкие" случаи, считая, что катастрофических вовсе не бывает.
То есть вот так писать — нормально:
try
{
buffer = new byte[1024*1024*1024];
} catch (OutOfMemoryException)
{
// not enough address space to get a large chunk; fallback to the iterative algorithm:
buffer = new byte[1024*1024];
useSlowHashing = true;
}
А вот так — глупость:
try
{
s = new Socket();
}
catch(OutOfMemoryException)
{
// execution engine failed to process the static or instance constructor call.
// There is not much we can do, but still I'll try to use a different approach
s = Statics.SharedSocketForSlowCommunication;
}
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, SergeyT., Вы писали:
ST>A system failure is an execution error that cannot be handled programmatically. For example, you really cannot handle an out-of-memory exception resulting from the Just-in-Time (JIT) compiler running out of memory.
Очевидно, что здесь идет речь о ExecutionEngineException (с сообщением "out of memory"), а не об OutOfMemoryException. JIT compiler не должен бросать OutOfMemoryException, если он это делает, это мега-глупость.
Здравствуйте, SergeyT., Вы писали:
ST>The sad fact is that CRL 2.0 cannot distinguish among any points on this spectrum.
Ну таки сделали мега-глупость разработчики CLR, даже умная книжка это подтверждает
ST>My best recommendation is that you treat OutOfMemoryException like any other application exception. You make your best attempts to handle it and ramain consistent. In the future, I hope the CLR can do a better job of distinguishing catastrophic OOM from the 1 GB byte array case. If so, we might provoke termination of the process for the catastrophic cases, leaving the application to deal with the less risky ones. By threating all OOM cases as the less risky ones, you are preparing for that day. ST>Christopher Brumme[/q]
Один-в-один то, что я написал в той ветке. Пытаемся обработать, не получилось — извините.
ST>P.S. Это все из той же Framework Design Guidelines.
Спасибо, уже читаю
... << RSDN@Home 1.2.0 alpha 4 rev. 1228>>
Re[4]: Framework Design Guidelines 2nd edition
От:
Аноним
Дата:
11.07.09 09:32
Оценка:
Здравствуйте, MozgC, Вы писали:
MC>Скачали, будем читать
4ebooks.org/2009/06/03/framework-design-guidelines-conventions-idioms-and-patterns-for-reusable-net-libraries-2nd-edition.html
