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

... 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

> 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

> 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

Reply via email to