Mike Small wrote: > > I'm not sure I follow. How is this different from, say, C++? You > can throw any type as an exception there too. I've actually seen C++ > code that says "throw 10", "throw "file not found error"", and > "throw OurSocketException(portnum, error_code)", along with exceptions > that are only meant as a sort of goto (do Perl people ever use die > as goto?). [...] Would anyone say C++ doesn't have real > exception handling?
Indeed, it's not just something you "have" or "don't have"... C and Perl are different from C++ insofar as C++ has a little more explicit syntax, support for catching specific types while letting others past, and syntax for declaring what can be thrown to facilitate static checking. But C++ does not have "finally", which is simply the trivial case of catching every exception, doing something, and then rethrowing the exception. It could, but there are philosophical objections (along the lines of "There's Another Way To Do It So Do That Instead"). But that's certainly just a little further down on a sliding scale. Java is further down the scale (for better and worse), with explicit type rules about what exceptions are and how they're enforced by static analysis, along with supporting "finally". Which is better? Depends! All of it can be misused badly, but on the Perl/C++ side, you can wind up with two different APIs that both want to throw a simply integer error code. Thus making it impossible for the catch logic to know which API threw it, and thus what it means. In Java, two APIs could throw instances of Exception, causing a similar problem. ... Which begs the answer to your question: Yes, people use die as goto. People use longjmp as goto. People use throw as goto. Exceptions have an association with concepts like "error case" and "should rarely happen"; but that is entirely wrongheaded. Exceptions are simply another kind of flow control. There are some low-level implications in terms of CPU efficiency, but it's just a matter of unwinding the stack until a point is found where some code should run, and then adjusting the instruction pointer. Within a single stack frame, it reduces to simply being a goto. Some languages (Perl, Java, others...) approach exceptions as "rare" and so have implementations that deter their use in high-performance scenarios -- so it's often a question not of program structure, but optimization and frequency. ... So on the C side, you can implement all of that by writing your own exception code and making sure that every API you use honors your conventions. As you slide down to the Java side, you lose control over the implementation details and you (probably needlessly) lose some complexity, but you gain standardization for how to find exception handlers and how to determine when a handler should apply to a given thrown value. Perl lacks both the high-level of efficiency possible with C's longjmp and the high level of standardization & structure provided by Java's (Throwable / try / catch / finally / throws) types & syntax. It's not unusable for everything. But it's not usable for everything. > Perl 6 exceptions look really interesting, from the little bit I've > read about them. I've never seen anything in other languages where > something can look like a return value but still throw itself as an > exception depending on what you do with it. Is this something with > roots in another language or completely new? Ecclesiastes 1:9, eh? Everything about Perl is novel in its particular combination, but little or nothing about modern computing is without antecedent. > I haven't done much Java outside of courses. It has standard > exception classes in kind of the same way it has standard everything, > like .NET does, right? That's not a fair comparison to me. That's > largely a single vendor's effort as opposed to a community's. There are plenty of languages written by individuals and communities that have rigid language specifications. It's somewhat a matter of style -- deliberate design vs. organic evolution. And there are counterexamples as well. > It's > easier for them to have uniformity. I'll take Perl and C++, with > whatever quirks or inconsistencies they have over those guys any day, > partly just because of their imposed uniformity: e.g. "thou > shalt not multiply inherit." But I guess I can see how it's helpful > when you have a bunch of people who are supposed to all be on the > same page to work with something where so many decisions were made > already. So maybe these people more left because they wanted > something with a single coding standard right across the whole > community than because of a missing or flawed language feature? Basically. And taking Perl despite its quirks is fine -- use Perl when Perl makes sense. What is off-putting (it's a thread about marketing after all) is the only-slightly-different attitude of the fanatic: "I'll use Perl _because_ it lacks imposed uniformity." > So in Java, the language doesn't let you throw anything that's not > derived from a certain class in their standard library, namely > java.lang.Throwable? That seems kind of hokey to me, the language > knowing about the library that way. And it's an abstract class > too, not even an interface, so that's all you can derive from, > right? Ew. It's really not bad in context. In Java everything is an object (or about to become one). Throwable has stuff that is used by the runtime to determine if the thrown object is the one being caught & then a bunch of utility material. One could have put that logic into Object, and then have been able to throw Integer and PrintWriter and all kinds of stuff. But that would seem to be asking for chaos to little real benefit. You can always subclass RuntimeException (or Exception, but that's another issue) with a class that includes the Integer or PrintWriter as a field. Is it less efficient? Sure. But this is Java. Looking for C/C++/D/Forth/etc efficiency in Java is like looking for it in Perl -- it's not there; not in that way. _______________________________________________ Boston-pm mailing list [email protected] http://mail.pm.org/mailman/listinfo/boston-pm
