Цепочки исключений в программировании: обработка ошибок через "обёртки". Сохранение исходной ошибки для отладки, упрощение обработки на верхних уровнях.
Сравнивайте с английским: нажмите на абзац — оригинал откроется в окне. Кнопка EN под абзацем показывает его прямо в тексте.
Введение
Цепочка исключений, или оборачивание исключений, — это объектно-ориентированная техника программирования для обработки исключений путем повторного выброса перехваченного исключения после помещения его внутрь нового исключения. Исходное исключение сохраняется как свойство (например, «причина») нового исключения. Идея заключается в том, что метод должен выбрасывать исключения, определенные на том же уровне абстракции, что и сам метод, но без потери информации с нижних уровней. Например, метод для воспроизведения файла фильма может обрабатывать исключения при чтении файла, повторно выбрасывая их внутри исключения, связанного с воспроизведением фильма. Пользовательскому интерфейсу не нужно знать, произошла ли ошибка при чтении фрагмента байтов или при вызове EOF. Ему требуется только сообщение об исключении, извлеченное из причины. Уровень пользовательского интерфейса будет иметь свой собственный набор исключений. Тот, кто заинтересован в причине, может увидеть трассировку стека во время отладки или в соответствующем журнале. Выброс исключений подходящего типа особенно важен для проверяемых исключений в языке программирования Java, и начиная с версии 1.4 почти все исключения поддерживают цепочки. В средах выполнения, таких как Java или .NET, существуют инструменты, которые подключаются к среде выполнения и каждый раз при возникновении интересующего исключения записывают отладочную информацию, которая была в памяти в момент выброса исключения (значения стека и кучи). Эти инструменты называются перехватом исключений и предоставляют информацию о «первопричине» исключений в программах Java, работающих в производственной, тестовой или разрабатываемой среде.
Exception chaining, or exception wrapping, is an object oriented programming technique of handling exceptions by re throwing a caught exception after wrapping it inside a new exception. The original exception is saved as a property (such as cause) of the new exception. The idea is that a method should throw exceptions defined at the same abstraction level as the method itself, but without discarding information from the lower levels. For example, a method to play a movie file might handle exceptions in reading the file by re throwing them inside an exception of movie playing. The user interface doesn't need to know whether the error occurred during reading chunk of bytes or calling eof It needs only the exception message extracted from cause. The user interface layer will have its own set of exceptions. The one interested in cause can see its stack trace during debugging or in proper log. Throwing the right kind of exceptions is particularly enforced by checked exceptions in the Java programming language, and starting with language version 1.4 almost all exceptions support chaining. In runtime engine environments such as Java or NET there exist tools that attach to the runtime engine and every time that an exception of interest occurs they record debugging information that existed in memory at the time the exception was thrown (stack and heap values). These tools are called Exception Interception and they provide "root cause" information for exceptions in Java programs that run in production, testing, or development environments.