On Mon, Aug 12, 2013 at 1:35 AM, Bennie Kloosteman <[email protected]>wrote:
> The work on .NET on a throw is clear > > a) Create a new Exception object ( there is your 10* cost already + branch > miss , cache misses from the following etc ) > b) copy methods from the stack to Exception object ( or whole stack ) > c) load / copy map of address to method name.* change stack to strings > now ( or in global handler) > d) unwind stack till a catch handler is found > Why would you need to do "c" during the throw? It seems like you can easily do this after. Also, "b" could be done incrementally as the stack is unwound, preventing a full stack walk in the case the exception is caught near the throw. (though certainly at some cost) > Return values are fast. This is my criteria a,b,c. > > Yes, though I see no reason why this should not be true for exception > handlers when the Liskov implementation technique is used. @Shap - After some digging, I'm now confused about this comment. Were you talking about the original CLU exception mechanism? http://www-public.it-sudparis.eu/~gibson/Teaching/CSC7322/ReadingMaterial/LiskovSnyder79.pdf As of that paper they only allowed one-level exception signaling, which sounds to me like a form of structured return value.
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
