Browse thread
[Caml-list] Catching exceptions into strings
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: | 2002-06-11 (17:45) |
From: | David Chase <chase@w...> |
Subject: | Re: [Caml-list] Catching exceptions into strings |
At 05:37 PM 6/11/2002 +0200, Xavier Leroy wrote: >> where it happens to be necessary, and optimizing it out when it is not? > >I'm more skeptical here. I'm yet to see a practical compile-time >analysis that can prove that an integer expression is not zero in any >but the most trivial cases (the expression is a constant or a for-loop >index). (By "integer", I mean machine integers with modulo arithmetic.) Trivial is pretty common, and for-loop index is an important common case. A "constant propagation" lattice can also be a good deal more interesting than just constants. I've worked on a compiler that propagated information about type inference, null/not, relationship to various array bounds, positive/negative/zero/not, and a friend and I have discussed the usefulness (not the feasibility, which is dead-simple) of propagating information about set/cleared/smeared bits. It is plausible, if you are working in the absence of reflection, that a compiler might infer the non-zero-ness of array elements and object fields. If, on the other hand, you are working in a world where programs have reflective access to data, then all bets are off (as in, once upon a time, and maybe still, the native code in java.lang.sql went out and fiddled with the private fields of strings, and I know of people at a Famous Computer Company who wrote native code that twiddled the private fields of Java file-related classes in order to get a sort of poor man's asynchronous I/O.). I've also learned to be incredibly skeptical about any programmer's assertion that "X cannot possibly happen", and throwing an exception means that you can at least talk about what happens when X does happen. Just for instance, a server program can be written to catch any exception at the "outside" of a service thread, and report it both to the web page and the debug log, and then continue running as before. This is much better than the server falling over and needing a restart. One approach to this problem, though I don't know if anyone has seriously tried it, would be to ask the programmer to supply the missing proof steps, and if those steps connect the dots, then the checks come out. This does require a cleverer proof engine in the compiler, but I'd trust that a lot more than just believing some claim that I read in a comment or a build script. And lastly, what does it cost to do the check? Surely, you did not omit the check in the name of efficiency (he says, smirking) without first measuring the cost? That would be (ahem) premature optimization, which is well-known as the root of all evil. :-) David Chase ------------------- To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ Beginner's list: http://groups.yahoo.com/group/ocaml_beginners