another frustrating learner question, CLOS
in [Lisp]
|
Prev: Anybody mind to translate this Felleisen quote from German to English
Next: Macros and anonymous functions
From: Zach Beane on 27 Feb 2010 20:01 Ron Garret <rNOSPAMon(a)flownet.com> writes: > In article <873a0mmd85.fsf(a)hangup.portland.xach.com>, > Zach Beane <xach(a)xach.com> wrote: > >> Ron Garret <rNOSPAMon(a)flownet.com> writes: >> >> > In article <87aauumfi0.fsf(a)hangup.portland.xach.com>, >> > Zach Beane <xach(a)xach.com> wrote: >> > >> >> Ron Garret <rNOSPAMon(a)flownet.com> writes: >> >> >> >> >> > There is no way to catch exceptions (which I learned the hard way >> >> >> > while managing a project that was using Perl in production). >> >> >> >> >> >> This is generally considered a feature of Perl. What aspect of Perl's >> >> >> support for catching exceptions do you feel disqualifies it per your >> >> >> definition of the term? >> >> > >> >> > I have to give you a bit of context: I was brought in as an interim CTO >> >> > in a situation where the actual CTO (and founder of the company) had >> >> > gone off the deep end and was pretty much bringing the company down. So >> >> > I was not (and never became) very familiar with the code base. All I >> >> > know is that there were a bunch of perl scripts in production, one of >> >> > which was failing intermittently for unknown reasons. I suggested that >> >> > we just wrap the entire script in whatever the perl equivalent of a TRY >> >> > block was so we could catch the error, whatever it was, and I was told >> >> > that was not possible. At that point I made a command decision to >> >> > rewrite the entire system in Python, which was well received by both >> >> > upper management and the engineering team, and not just because catching >> >> > errors ought to be a complete no-brainer in any reasonable programming >> >> > language. >> >> >> >> By this reasoning, Python can't catch exceptions either. >> > >> > Huh? How do you figure that? >> >> To demonstrate that Python doesn't have exceptions, all you have to do >> is join a project with a Python script that fails intermittently, >> suggest that it be wrapped in an exception handling block, and be told >> that it isn't possible. (It's not difficult to produce a Python script >> like that.) > > Really? How do you do it? if something_awful(): print "Uh, oh, there's a problem!" os._exit(1) >> Then you can make a command decision to switch to Perl, >> which does support catching exceptions. > > It should be noted at this point that you are the one who introduced the > concept of catching exceptions into the conversation, not me. I didn't edit the part I quoted at the start of this article, where you wrote "There is no way to catch exceptions". > What I was talking about was catching *errors*. That's what you wrote in your "bit of context", but not initially. > Catching exceptions can be the same thing as catching errors but it > might not be. And in particular, in Perl, I was given to understand > that it is not, though I am certainly no Perl expert and I am always > happy to be enlightened. The usual way to do exception handling in Perl is to combine die() (or similar) and eval { ... }. There are modules that make the syntax look like other languages. Zach
From: Tim Bradshaw on 27 Feb 2010 20:12 On 2010-02-28 01:01:37 +0000, Zach Beane said: > The usual way to do exception handling in Perl is to combine die() (or > similar) and eval { ... }. There are modules that make the syntax look > like other languages. And of course, this is why Perl is in fact Lisp: there are modules which make the syntax convenient, for almot arbitrary values of "convenient".
From: Ron Garret on 27 Feb 2010 21:10 In article <87y6iekwb2.fsf(a)hangup.portland.xach.com>, Zach Beane <xach(a)xach.com> wrote: > Ron Garret <rNOSPAMon(a)flownet.com> writes: > > > In article <873a0mmd85.fsf(a)hangup.portland.xach.com>, > > Zach Beane <xach(a)xach.com> wrote: > > > >> Ron Garret <rNOSPAMon(a)flownet.com> writes: > >> > >> > In article <87aauumfi0.fsf(a)hangup.portland.xach.com>, > >> > Zach Beane <xach(a)xach.com> wrote: > >> > > >> >> Ron Garret <rNOSPAMon(a)flownet.com> writes: > >> >> > >> >> >> > There is no way to catch exceptions (which I learned the hard way > >> >> >> > while managing a project that was using Perl in production). > >> >> >> > >> >> >> This is generally considered a feature of Perl. What aspect of > >> >> >> Perl's > >> >> >> support for catching exceptions do you feel disqualifies it per your > >> >> >> definition of the term? > >> >> > > >> >> > I have to give you a bit of context: I was brought in as an interim > >> >> > CTO > >> >> > in a situation where the actual CTO (and founder of the company) had > >> >> > gone off the deep end and was pretty much bringing the company down. > >> >> > So > >> >> > I was not (and never became) very familiar with the code base. All I > >> >> > know is that there were a bunch of perl scripts in production, one of > >> >> > which was failing intermittently for unknown reasons. I suggested > >> >> > that > >> >> > we just wrap the entire script in whatever the perl equivalent of a > >> >> > TRY > >> >> > block was so we could catch the error, whatever it was, and I was > >> >> > told > >> >> > that was not possible. At that point I made a command decision to > >> >> > rewrite the entire system in Python, which was well received by both > >> >> > upper management and the engineering team, and not just because > >> >> > catching > >> >> > errors ought to be a complete no-brainer in any reasonable > >> >> > programming > >> >> > language. > >> >> > >> >> By this reasoning, Python can't catch exceptions either. > >> > > >> > Huh? How do you figure that? > >> > >> To demonstrate that Python doesn't have exceptions, all you have to do > >> is join a project with a Python script that fails intermittently, > >> suggest that it be wrapped in an exception handling block, and be told > >> that it isn't possible. (It's not difficult to produce a Python script > >> like that.) > > > > Really? How do you do it? > > if something_awful(): > print "Uh, oh, there's a problem!" > os._exit(1) If you really think an inadvertent call to os._exit is a possibility that's still pretty easy to handle: Python 2.6.1 (r261:67515, Jul 7 2009, 23:51:51) [GCC 4.2.1 (Apple Inc. build 5646)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> from safe_call import safe_call >>> import os >>> def barf(): .... os._exit(1) .... >>> safe_call(barf) System exit: 1 >>> barf() [ron(a)mickey:~]$ Implementing safe_call is left as an exercise. > >> Then you can make a command decision to switch to Perl, > >> which does support catching exceptions. > > > > It should be noted at this point that you are the one who introduced the > > concept of catching exceptions into the conversation, not me. > > I didn't edit the part I quoted at the start of this article, where you > wrote "There is no way to catch exceptions". Ah. You're right. I did say that. > > What I was talking about was catching *errors*. > > That's what you wrote in your "bit of context", but not initially. Well, initially I wasn't trying to be precise. It's actually very hard for me to be precise about the problem because I never completely understood it. All I know is that I was told that there's no way in Perl to do the equivalent of safe_call. I found this hard to believe (still do), but the entire engineering team insisted it was true. > > Catching exceptions can be the same thing as catching errors but it > > might not be. And in particular, in Perl, I was given to understand > > that it is not, though I am certainly no Perl expert and I am always > > happy to be enlightened. > > The usual way to do exception handling in Perl is to combine die() (or > similar) and eval { ... }. There are modules that make the syntax look > like other languages. There was some reason why that wouldn't work. I think it might have had something to do with there being ways to have errors in perl that did not have the semantics of calling die(). But I don't remember the details. If you really want to know I could probably contact one of them and ask. rg
From: Giovanni Gigante on 28 Feb 2010 06:50 Ron Garret wrote: > Catching exceptions can be the > same thing as catching errors but it might not be. And in particular, > in Perl, I was given to understand that it is not, though I am certainly > no Perl expert and I am always happy to be enlightened. The usual tools are the block form of eval, and the variable $@ (aka $EVAL_ERROR if you "use English").
From: Tim Bradshaw on 28 Feb 2010 07:18
On 2010-02-28 02:10:26 +0000, Ron Garret said: > There was some reason why that wouldn't work. I think it might have had > something to do with there being ways to have errors in perl that did > not have the semantics of calling die(). But I don't remember the > details. If you really want to know I could probably contact one of > them and ask. To me this sounds like some terrible design flaw in the application which people (not you!) are busily blaming on the implementation language rather than trying to put right. This doesn't mean I think they were lying to you - I don't - rather that, as is quite common, they either did not understand the problem, or were in a state of denial about it. This kind of thing is quite common - I've had discussions with people who blamed catastrophically bad performance of a tool on slow performance of the implementation language (and, I think, honestly believed that) when I knew, because I'd measured it, that it was due to changing a single line in a ~20M file by rewriting the whole file, and doing this tens of thousands of times, resulting in hundreds of GB of I/O. Don't misunderstand me - Perl's error handling is deficient, but I'm not sure I'd be willing to say that it makes it impossible to handle errors. |