On Wed, Mar 17, 2010 at 09:35:02AM -0400, John Redford wrote:
> > You (they?) don't count eval { die } as exception handling?  Or was
> > this an earlier version they left?
> Not really, no.  The key problem with Perl's "exceptions" is that a thrown
> exception value can be almost anything.  This is cool enough when all of the
> code is "your" code -- controlled by one set of people at least -- and you
> throw whatever makes sense to you.  But consider what happens when you try

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?).  Perhaps some people derive from std::exception, but
certainly not universally.  The code base I maintain uses something
quite different that, if it were used by other programmers directly
instead of from in front of a COM or .NET interface, would probably
be objectionable to them.  Would anyone say C++ doesn't have real
exception handling?

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?

> to integrate a variety of modules and codebases, each of which throws
> something different -- you wind up with a muck of code that examines the
> value to determine whose exception it is, so you can determine if you want
> to handle it or re-throw it.
> Perl's exception handling is far closer to that of C -- setjmp/longjmp --
> than that of Java et al.

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

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.

Mike Small

Boston-pm mailing list

Reply via email to