trapping type conversion errors

[Vapuser <vapuser(at)catspaw.jpl.nasa.gov>]

  I may be missing something, but are type conversion errors
  untrappable? 

  Consider the following

PRO junk
  catch,error
  IF error NE 0 THEN BEGIN 
    message,!error_state.msg,/info
    return
  ENDIF

  t = ['01','aa']
  tt = fix(t)
  ;print,"I'm here"
  ;message,!error_state.msg,/info

  help,!error_state,/st
END

>From this snippet of code I conclude that the only way to 'trap' these
errors is to set !quiet=1 (just to get rid of the messages from the
interpreter) and then actually test the !error_state structure, either
the 'name' (=IDL_M_TYPCNVERR) or the 'code' (-97)

Am I wrong?

Am I alone in finding this a mite strange? Could we put in a request
that everything that sets !error_state.code to something != 0 be
trappable? Is there some reason, other than inertia, that this isn't
so that I just don't know about?

Also, math errors are only 'trappable' using 'check_math()', right?

whd
-- 
William Daffer: 818-354-0161: William.Daffer@jpl.nasa.gov