>
>
>>>
>> 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.
>>
>
> Well, no, you don't. Because if you really wanted that, you wouldn't be
> interested in error codes, because those don't give you any of that.
>
Yes I do .. I have had loops in production causing stack overflow which you
can find by what sequence of methods ran in the loop .. this is invaluable
to reproduce the problem.
>
> But assuming you *do* want that, you still don't need to *copy* the stack
> frame. What you need to do is *preserve* the stack frames. As long as the
> stack frame is preserved, you can produce a pretty string later if you find
> that you need it.
>
Which requires the runtime to gurantee that the adress to lookup is valid .
>
> So we need to ask: what might cause the stack fragment *not* to be
> preserved. The answer is "procedure calls". That is: newly created stack
> frames. But wait! Those stack frame creations involve mandatory stores for
> initialization purposes. All we need to do is make sure they don't happen
> on the stack we are currently trying to preserve. To do that, all we really
> need to do is make them happen somewhere else. Which could be on a newly
> allocated stack fragment (note this is only allocated in the handler), or
> it could be a new section of the existing stack *below* the exception
> frames (i.e. in a stack position that we would normally think of as "newer
> than" those frames).
>
> Several people here have said that they don't want *anything* in the
> stack frame to change because of debugging. I would hazard to guess that
> even CLR doesn't provide that. If handler code modifies a parameter, my
> guess is that the backtrace shows the modified value. Somebody should check
> what happens with a test case. If you want that level of debugging, the
> right way to do it is to run a debugger and put a breakpoint on __raise().
>
>
>
>>
>>> 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.
>>>
>>
The explicit nature means resources are carefully tracked instead of being
carefully created and possibly reused.. finalisers will call the
destructor in C++ and dispose , Agree this is coding style and you can do
exceptions the same way - its just people dont because they dont expect
such errors to happen frequently .. eg a method with a return code visibly
gives equal weight to returning errors and doing something if you dont
return you get an error , an exception "hides" the error path and makes it
the callers prroblem.
>> 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..
>>
>
> This is a poor example, because this isn't a case that should be handled
> with exceptions in the first place.
>
Its quite common , does this string match a variaety of values each will
call compare..( in a typical naive impl) , is not null or not string.empty
is the same.
And is precisely the code people use to say exceptions are slow ..and about
the only time you need exceptions to be fast ...
When do you need "Errors" to be fast ..It must be in a loop and
1) When your using erros for control flow .. Which is bad
2) When your validating large amounts of possibly bad data . The above
is exactly the case when validating the strings or similar stuff like is
not null / empty.
> In more realistic code, argument validation failures would be handled as
> fatal errors, because they indicate a structural problem in the program.
> And we really shouldn't worry about a small marginal cost in what amounts
> to an exit() call.
>
>
Think GUI or validate html strings.. in a loop .
> I think you are saying that there are good examples of procedures that *
> should* return result codes of various forms. I agree. And having
> exceptions in the language doesn't prevent that in any way.
>
I have been saying that from the start . In 10 years of C# code i have
never found a case where excpetion performance would make a material
difference with the exception of user validation , errors should not be
common so why should you have them in a loop.
>
> But from a type system they are much rarer than you might think. The
> problem is that the procedure *must* return a value of the stated return
> type, even if it also returns an error code. There are many cases where we
> need to generate an error result without having anything plausible to
> return. In those situations, there are only two options that preserve type
> safety:
>
> 1. Exceptions, because the normal return path is not live and therefore
> the absence of a normally returned value doesn't matter - though we need to
> be careful about initializers in this case.
>
> 2. Using union values as return types.
>
>
Agree thats why validation excpetions are a pain , you tend to have lots of
objects and want to do Validate() but user data often has erros . The
other big ones .. you cant have expected excepetion type on an interface
.. and you cant pass excpetions accross processes so for web GUIS its
easier to return ValidationErrors rather than catch them and exract the
errors to be put into the page.
Ben
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
