comp.lang.idl-pvwave archive - RDF feed
type: channel
description: Messages from Usenet group comp.lang.idl-pvwave, compiled by Paulo Penteado
items: Re: Catching errors with widgets

Re: Catching errors with widgets
type: item
description: ian@gomez.jpl.nasa.gov (H. Ian Novack) writes: > I a writing some widgets to do some simple things. One widget is for loading > bands from a multi-spectral image on disk. This widget gets the parameters > from the user and then calls another routine I wrote to extract the bands > from the file. > Fine. > But, if the user overestimates the size of the image, then my extraction > routine will hit end of file and die. The error will bubble up until I blast > out of my widgets and get the IDL> prompt again. I would rewrite your extraction routine to exit more gracefully, returning an error code to the calling routine. You can return the error code in a keyword to keep it compatible with the way it currently works. > I read in the manuals that you can get back into the widgets with RETALL and > XMANAGER, but I want this to happen automatically. I've fiddled with ON_ERROR, > ON_IOERROR, RETURN and such, but can't get it to work. > I *can* get it to not blast out, but then, when I try to load another image > (of the right size), I get the following error message: > % COLOR_QUAN: Variable is undefined: <UNDEFINED>. > % Execution halted at ILOAD_EVENT </home/avdev/ian/idlpro/widget/id_load.pro( > 188)> (COLOR_QUAN). > % Called from XMANAGER </usr/local/idl/lib/widgets/xmanager.pro( 402)>. > % Called from ID </home/avdev/ian/idlpro/widget/id.pro( 289)>. > % Called from $MAIN$ . > ILOAD_EVENT and ID are mine. The COLOR_QUAN is used to display the 24-bit > data I'm reading in on the 8-bit display. Obviously, I can't tell which > variable it's choking on. Why not? Try putting HELP statements just before the call to COLOR_QUAN to find out exactly what variables you're feeding it. I'd suggest putting a STOP command just before COLOR_QUAN, but I understand that this may cause problems with widgets in newer versions of IDL. > Finally, I can't tailor my extraction routine too much, as it is a general > utility that people use often. That's one of the beauties of using keywords. > Any…
creator: thompson
date: 1993-04-08T13:37:11-00:00

Re: Catching errors with widgets
type: item
description: I don't know if this is relevant to your problem or not, but I was getting the same Variable is undefined message when I used ON_IOERROR to trap errors in my widget based application. The following dialog between support@rsinc.com and me may be relevant: >> 4. There appears to be a problem with the ON_IOERROR statement (which I can >> only get to manifest itself with widget-based applications). >> ... >> This application eventually leads to an IDL error if the ON_IOERROR trap is >> taken at least once. The error type and its location don't seem to be >> reproducible.If there is no Xmanager background procedure, errors still occur >> but much less often. (I ran into this behavior when my production code >> produced the error "Array has corrupted descriptor". I knew something was not >> kosher!) > This is a known problem in IDL 3.0 (and perhaps earlier versions). It > has been fixed and will be available in the next version of IDL after > version 3.0. You are correct that it involves the use of ON_IOERROR > in widget applications. > Alan Youngblood > > support@rsinc.com / /\ / > 303-786-9930 x320 / /_/ /__ Technical Support ---- Harvey Rarback Internet: rarback@bnlx26.nsls.bnl.gov Brookhaven National Lab ESnet/NSI: BNLX26::RARBACK Upton, NY 11973 BITNET: RARBACK@BNL (516) 282-3758
creator: rarback
date: 1993-04-08T14:48:07-00:00

Re: Catching errors with widgets
type: item
description: In article <thompson.734276231@serts.gsfc.nasa.gov>, thompson@serts.gsfc.nasa.gov (William Thompson) writes... > ian@gomez.jpl.nasa.gov (H. Ian Novack) writes: > >> I *can* get it to not blast out, but then, when I try to load another image >> (of the right size), I get the following error message: > >> % COLOR_QUAN: Variable is undefined: <UNDEFINED>. >> % Execution halted at ILOAD_EVENT </home/avdev/ian/idlpro/widget/id_load.pro( >> 188)> (COLOR_QUAN). >> % Called from XMANAGER </usr/local/idl/lib/widgets/xmanager.pro( 402)>. >> % Called from ID </home/avdev/ian/idlpro/widget/id.pro( 289)>. >> % Called from $MAIN$ . > >> Obviously, I can't tell which variable it's choking on. > > Why not? Try putting HELP statements just before the call to COLOR_QUAN to > find out exactly what variables you're feeding it. I'd suggest putting a STOP > command just before COLOR_QUAN, but I understand that this may cause problems > with widgets in newer versions of IDL. > My experience is that the message % COLOR_QUAN: Variable is undefined: <UNDEFINED>. indicates an internal error in the IDL executable, and not a problem with the Ian's IDL code. Note that ordinarily if one has an undefined variable, IDL will display the name of the variable in the error message. The fact that above error message does not give the name of the undefined variable shows that it is not one of the variables that is being fed to COLOR_QUAN, but rather an internal IDL error. One known source of this type of the problem is the On_IOerror statement. Very occasionally, ON_IOError appears to corrupt the IDL stack so that an error can appear much later (usually in a widget program). I know RSI is working on this although I don't know if they have a fix ready or the next release. Wayne Landsman landsman@stars.gsfc.nasa.gov
creator: landsman
date: 1993-04-08T18:18:00-00:00