comp.lang.idl-pvwave archive
Messages from Usenet group comp.lang.idl-pvwave, compiled by Paulo Penteado

Home » Public Forums » archive » Error Handling Change in IDL 8
Show: Today's Messages :: Show Polls :: Message Navigator
E-mail to friend 
Return to the default flat view Create a new topic Submit Reply
Re: Error Handling Change in IDL 8 [message #73005 is a reply to message #72910] Tue, 19 October 2010 10:27 Go to previous messageGo to previous message
David Fanning is currently offline  David Fanning
Messages: 11724
Registered: August 2001
Senior Member
Paul van Delst writes:

> Sorry, man.

> Think of it as fixing your house after a storm blows through, as
opposed to fixing your house after you put the ladder
> through the living room window (and then proceed to knock over your antique Tiffany lamp from the table....)

This sounds suspiciously like the advice Coyote often
gives me. I don't like this any better than I like his. :-(

> Can you replace that one line of code
> ON_ERROR, 2
> in your routines with a CATCH construct that replicates the behaviour you want?

Sigh...Yes, I can replace them with CATCH, which is what
I am doing as I find them.

> If so (I don't think there should be a difference between functions
and procedures in this case, but ?), put that code
> in an include file and simply replace all instances of
> ON_ERROR, 2
> with
> @<your catch construct include file>
>
> You can trivially do this replacement with a script (see a previous post of mine about this).

Well, in functions the CATCH returns some value.
In procedures, it doesn't. Most of these ON_ERROR,2 calls
(but not all) are in functions, and I try to be a bit
careful about what I return. I'm not sold on the notion
of a generic CATCH handler.

> FWIW, if you come up with the include file and create a branch for me in your subversion repository, I can check that
> branch out, do the replacements, and commit the changes (I will need write access so I understand if that makes you feel
> a bit squirrelly and say no). You can then test the changes in the branch (I can also if you have standard tests for the
> code). If you like what you see, we can merge the branch into the trunk. If you don't like it, we can simply delete the
> branch.

It is not really my library routines I am worrying
about. I'm pretty careful with Library routines.
I'm less careful when writing one-offs to
do science. It's these routines I am struggling with
at the moment. It's just disconcerting to get error
messages that don't mean a damn thing to me and do
nothing to help me solve the problem.

Alright, I'm going to quit whining about it. But
I still think changing the way error handling works
was a terrible idea and almost guaranteed to
antagonize long-time customers. (If I'm the only
one antagonized, as it appears, then perhaps
Coyote is right that "Nobody uses damn error
handling anyway!")

Cheers,

David

P.S. I'm not sure how to use a Ruby script. Do you have
that Perl script around? I can think of a few ways to use
that! Thanks.


--
David Fanning, Ph.D.
Fanning Software Consulting, Inc.
Coyote's Guide to IDL Programming: http://www.dfanning.com/
Sepore ma de ni thui. ("Perhaps thou speakest truth.")
[Message index]
 
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Previous Topic: IDL runtime
Next Topic: IDL 8.0 garbage collector issue.

-=] Back to Top [=-
[ Syndicate this forum (XML) ] [ RSS ] [ PDF ]

Current Time: Thu Oct 09 23:30:42 PDT 2025

Total time taken to generate the page: 0.08057 seconds