> First, there is absolutely no need to create a new exception object
> whenever you throw an exception. The exception object can be constructed
> statically and a reference to it can be thrown. Returning that reference
> has identical cost to returning an error code. No, you won't get dynamic
> per-exception information, but you were perfectly willing to give that up
> by returning error codes, so why is everybody whining about that?
>
How can this be if its a user created type ? Possibly with a param ? I
can see it working for some hand picked excpetions like FastException but
not MyException (appErrorCode);
>
> Second, there is absolutely no need to copy stack frames when an exception
> is thrown. It is not a requirement that the stack remain immutable, and it
> is not a requirement that the stack be preserved from the originally thrown
> exception. You are only going to perform a backtrace for an exception that
> is *not caught. *In that case, no code has run that might modify the
> stack, and the original stack is alive and well. You can then perform a
> backtrace from there. All that is needed is to preserve the SP and PC from
> which the original throw occurred. Some of you have been imagining richer
> mechanisms than this, but once again you all seem perfectly willing to
> tolerate not getting those mechanisms in the error code style of design.
>
To me i really want to know what is on the stack where it throws and in
string format ..eg in release runtime loop throwing out of stack . I can
see the line of code and work out how the error can happen without
reporducing all the conditions.
>
> Unwinding the stack until a catch handler is found is generally *cheaper* than
> conventional error return. Both mechanism are doing precisely the same
> thing; the error return case does it more explicitly, but that doesn't
> change the cost of it.
>
There is a coding style here here .. eg a resource is created cheap and
now has to be unwound .. nor do i believe this unwinding is cheaper..im
compraing it to validation where 90% of the time this is an issue . and
failure is this
int Compare (string str1 , string str2)
{
if ( str1.Length !=str2.Length)
return -1;
// do rarer validation
}
Nothing can be anywhere near this speed .. it will be inlined etc..
> Bennie notes that your map may change by DLL unload, but that's wrong. In
> order for that to happen, you had to hit a catch handler. At that point the
> original exception has been caught and you aren't ever going to see a stack
> trace from it. If a subsequent throw occurs, then it obviously can't be
> entangled with the DLL unload.
>
It cant happen in the CLR ( they took the easy way out - no unloading ) but
was thinking something ( but not exactly ) like concurrent GC thread
runssees no usage / code references to DLL throws it out to save memory (
perhaps even the JIT building the code into a code heap which is managed
as a GC / region) . Thread resumes - stack references are wrong.
>
> So the real problem here isn't the inherent cost of exceptions at all.
> It's the cost of creeping featurism.
>
Agree but i want my stack trace as strings at the source in 99% of live
code projects... :-)
Ben
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
