在操作系统中存储.net异常的位置 [英] where was stored .net exceptions in operating system

问题描述

操作系统中存储.net异常的位置

where was stored .net exceptions in operating system

推荐答案

您正在从完全成熟的结构化异常机制的早期实现者那里得到答案，当它在CLU和Ada中可用，但当时不是用C ++或其他更流行的语言。



为了理解，你需要了解一般的调用返回机制基于调用堆栈工作。如果你不清楚它，你将不得不学习它;只是阅读它，因为我不打算在这里解释它。无论如何，堆栈使用每个线程分配的一些内存。无论如何，多个调用和返回的集合在堆栈上创建数据数组，其在运行时的某个给定点存储所有返回点，参数和局部变量。多次返回后，执行最终将返回到第一次调用。调用和返回的序列，以及参数和局部变量值的所有实际值都存储在堆栈中，并且没有预编程，在整个应用程序的每次运行中它可能不同。



当您添加异常处理时，您必须为每个线程再创建一个堆栈：堆叠的尝试点。每个点都存储足够的信息，使环境可以从抛出异常的一个步骤返回到尝试点，但此信息中的一个重要项目是保留调用堆栈的状态。实际上，这可以是几个寄存器（堆栈指针）的值。当然还有很多：你必须存储CPU的状态。它的实现很大程度上取决于CPU架构。因此，异常传播就像一台时间机器：您可以随时回到其中一个尝试点。如果您学习了C或C ++，您可能熟悉称为long jump的系统调用，这是一种绕过通常的调用返回机制的方法。这就像拯救一个电脑游戏：你节省了一些时间点，如果发生致命问题，可以回来，好像什么也没发生，但你知道这个问题。我已经尝试在我过去的答案中描述这个想法： C＃构造函数中的异常是否导致调用者分配失败？ [ ^ ]。 />


现在，为什么这个异常信息是一堆对象，而不仅仅是一个存储？因为线程经过调用序列并以某种不可预测的顺序返回（一般情况下），并且通过一些尝试点序列，所以这个序列也是不可预测的，在不同的运行中可能是不同的。随着执行的进行，你会在堆栈上推送每个尝试点，并且当抛出时异常的传播会回溯到时间，所以你跳回到堆栈上推送的最后一个尝试点并弹出它。然后，根据处理程序，您进入新的调用返回序列转发，或者重新抛出异常抛出一个不同的处理技术（一种不同的处理技术），并将异常传播回到更早和更早的时间试试点。所以，在线程的所有可能的运行中，你总是将一个try点推送到异常堆栈或弹出它。



这是一个高度简化的模式，主要关注运行时和数据结构。

-SA

You are getting an answer from the very early implementor of the fully-fledged structured exception mechanism, when it was available in CLU and Ada, but not in C++ or other more popular languages of that time.

For understanding, you need to understand how the general call-return mechanism works, based on the call stack. If you don't clearly understand it, you will have to learn it; just read about it, as I am not going to explain it here. Anyway, a stack uses some piece of memory allocated per each thread. Anyway, the set of multiple calls and returns creates the array of data on the stack which stores all the return points, parameters and local variables at some given point of runtime. After multiple return, the execution will eventually get back to the very first call. The sequence of calls and returns, with all the actual values of parameters and local variable values is stored on the stack and is not pre-programmed, it can be different in each run of the thread of the whole application.

When you add exception handing, you have to create one more stack per thread: the stack of "try" points. Each point stores enough information to give the environment the possibility to get back to the tried point in one step from the point when an exception is thrown, but one of the important item in this information is to preserve the state of the call stack. In practice, this can be a values of couple of registers (stack pointer). There is a lot more, of course: you have to store the state of CPU. The implementation of it strongly depends on the CPU architecture. So, exception propagation is like a time machine: you can always get back in time to one of the "try" points. If you learned C or C++, you could be familiar with the "system" call called "long jump", a method which bypasses the usual call-return mechanism. This is like "saving" a computer game: you save some point in time and, in case of fatal problem, can get back as if nothing happened, but you somehow know about the problem. I already tried to describe that idea in my past answer: Does Exception in C# Constructor Cause Caller Assignment to Fail?[^].

Now, why this exception information is a stack of objects, not just one "storage"? Because the thread goes through the sequence of calls and returns in some unpredictable order (in general case), and passes through some sequence of try points, so this sequence is also unpredictable, can be different in different runs. You push each try point on stack as the execution goes, and propagation of an exception when on is throws goes back in time, so you jump back to the last try point pushed on stack and pop it. Then, depending on the handler, you go into the new call-return sequence forward, or re-throw an exception of throw a different one (one of the distinct handling techniques), and the exception is propagated back in time to earlier and earlier try point. So, in all possible runs of the thread, you always push a try point to exception stack or pop it.

This is a highly simplified schema focusing mostly on runtime and the data structures.

—SA

这篇关于在操作系统中存储.net异常的位置的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！