>
>
>>
> Why write code using two different error return methods? Personally I
> think writing solid bug-free code once is enough. I'd like to stem the
> geometric expansion caused by mechanisms which require us to write two
> versions of code.
>
I dont think this is a big deal
- You only write it once really, the 2nd case is just a wrapper if
Tryparse == fail then throw . A framework could perhaps create such a
wrapper automatically. So it boils down to 2 minutes of code ( maybe 5 if
you want fine grained exceptions) and 100bytes on the exe/dll size per
method.
- Only a handful of methods really need it , methods which occur in
tight loops . In most cases where you see lots of exceptions eg IO the
cost of the operation dwarfs the throw cost of errors .
Hard logic errors are normally handled by finally or left if critical so
its really only parsing and validation . With validation i hit it a bit
, people normally care about defining the type of error and there is no
way of saying in an interface it can throw exception abc ( which is an
issue with exception) so i need to do this
public IEnumerable<ValidationResult> Validate(ValidationContext
validationContext)
{
if (Qty == 0 )
yield return new ValidationResult("No Qty", new string[] {
"Qty" });
}
and wrap it anyway with an exception throwing handler ( though the handler
is in a different class) .
Even tryparse methods can still cause exceptions (ThreadAborted
,OutofMemory , Stackoverun etc ) and the non format exceptions of parse
which is a useful feature. It would be nice if contracts specify what
types of exceptions are normally thrown .. at the moment msdn doco and
reflector searches is the pnly way .
The best use of exceptions is the message pump on a single thread ( or any
kind of work dispatcher) .. where you know with certainty ( excepting :-)
critical failures ) that all errors will be caught regardless and control
returned to the loop. This can be very painful ( require discipline) with
c style calls to unwind go all the way back to the source.
>
>> Its kind of anoying too , sometimes i like to check thrown exceptions
>> in the debugger and when you have exceptions for logic you loose that
>> abbility.
>>
>
> That is a problem with debuggers and exception handling facilities. We
> shouldn't "solve" this by making exceptions slow and then telling
> programmers to not use them often, ohh and write a second version of all
> your functions incase someone needs them fast.
>
I stiill think "exceptions are errors" is a usefull concept even if thrown
and handled .. this is usefull eg for logging ..or debugging as above. eg
what went unusual in the run but was handled vs what went wrong. Note you
can eliminate one type of error but if it was common behavoiour to have a
throw as a fault then you could not do this .
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
