RE: Python or Perl for a Debian maintainance project?
Matthias Urlichs wrote:
> Julian Mehnle wrote:
> > So, if Python's exception handling were having a bug, you would
> > immediately recommend against using it?
>
> Of course not. But then again, I haven't yet found a bug in Python that
> causes an immediate and nonrecoverable crash.
> (See Perl bug #24589 for an example. That one was originally discovered
> using eval{}, but I managed to otherwise reproduce it.)
The word "eval" does not appear in bug #24589. But, for instance, "bless" does. So maybe the bug doesn't have anything to do with eval{}, but with bless() instead? I don't see how you can seriously infer from this a general recommendation against using Perl's exception handling.
> Andrew Suffield wrote:
> > My example has shorter functions (because it's split into several),
> > and no more indentation or line length.
>
> Exactly: Your example has _more_ functions, so the total line count is
> larger (for example, those "bool foo() {" and "}" lines). Then there's
> the aded complexity of passing arguments and of checking for errors
> more than once.
This is called "structure", and in software design and programming, it is usually considered a good thing(TM). Going by your argument, would you really consider it best having just one single huge main() function (yeah, a C analogy) and nothing else?
> Andrew Suffield wrote:
> > > therefore it's not all that well tested, and lots of little niggly
> > > difficult-to-reproduce bugs (reference counting, error reporting, et
> > > al.), still lurk in the corners when you do any kind of non-local
> > > exit.
> >
> > That's frequently unrelated (exit would have the same problems).
> > There are some subtle issues with global destruction still in 5.8.
>
> Frankly I don't care THAT much about destructors running on exit.
>
> I do care about cleanup code, both in the exception and non- case.
> Perl's Error::Simple's "try FOO finally BAR" construct doesn't execute
> BAR if FOO simply calls exit(), or is interrupted by ^C, or leaves by
> way of a non-local GOTO (which fortunately ;-) doesn't exist in Python,
> so that point isn't entirely fair).
>
> Python's "exit", OTOH, is just another exception, thus catchable.
Python's "try: FOO; finally: BAR" construct doesn't execute BAR if FOO simply calls os.kill(os.getpid(), 9), either. So what? Library code has no fucking business making any "exit()" or "os.kill(os.getpid(), 9)" calls in the first place, so your argument is pretty moot. If I want to raise an excetion in a library function, I do die() (or throw...), not exit().
You can catch ^C in Perl, by the way. Granted, it's not an exception. But you can catch it as a signal. Isn't that good enough?
> All of this doesn't change the fact that Perl code actually has to test
> for errors _all_the_time_ if it wants to be reliable -- it's very easy
> to overlook exactly the one call which will later bite you. :-/
Taking that ridiculous "library code calls exit()" argument aside, I don't see where you are taking that from. Perl code *doesn't* have to test for errors all the time if it uses eval{die()} or Error's try/throw. And it *can* be reliable that way.
Reply to: