On Thu, Aug 1, 2013 at 5:40 AM, Bennie Kloosteman <[email protected]>wrote:
> - 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 . > Your analysis breaks down for me for a few reasons.... (1) When writing library code, you don't know which functions need it, because you don't know when they will be used in other people's tight loops. If you don't support fast path error return for everything. you break the utility of the library for others. (2) return-value error handling side-steps the compiler's return-value assignment analysis. (it assumes all out arguments are assigned after the function returns normally) Personally, I want assignment analysis always, not only when using slow exception mechanisms. We can't force programmers to use structured error mechanisms, but we should not force them not to through performance problems. (3) I would really like the compiler to help me assure I've handled all possible fail-classes, and sometimes additionally know that I've exhaustively handled all currently existing specific failures. This is not possible if return values are side-stepping structured error mechanisms. (see below for more commentary here) ---- Note that none of the above require always using a *stack-unroll* exception mechanism, they simply require that a fast structured error mechanism exist. However, I think it makes more sense to have one fast structured error handling mechanism rather than two. Even tryparse methods can still cause exceptions (ThreadAborted > ,OutofMemory , Stackoverun etc ) and the non format exceptions of parse > which is a useful feature. > These exceptions are essentially exit(1), thankfully expressed in the more specific scope in which they are relevant. I have no trouble if these "true runtime exceptions" have a slow stack unroll. > 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 . > I agree. I also agree with Shap that current checked-exception proposals have been cures somewhat worse than the disease. Java's checked exception proposal doesn't even work that well, since I've seen code resort to throwing runtime exceptions to avoid the cumbersome overhead of checked exceptions. Personally, I find promise in experimenting with a few methods... (a) requiring all exceptions thrown by an assembly to derive from an assembly global exception-base, (b) inferring/checkin propagation of these 'assembly exception classes' at module boundaries, (c) condition handlers. -- However, I admit this is an interesting unsolved area.
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
