none
TRY/CATCH Not Catching RRS feed

  • Question

  • Hello, I have a simple example of an error being thrown even though it should be handled within a TRY/CATCH.

    Does anyone know why this is happening?

    See the combo1.Requery() below:

     

     

      loFrm = CREATEOBJECT("form1")
     
      loFrm.Show
    
    
    **************************************************
    *-- Form:         form1 (c:\azb-tfs-vm\test\trycatchtest.scx)
    *-- ParentClass:  form
    *-- BaseClass:    form
    *-- Time Stamp:   12/29/11 10:25:05 AM
    *
    DEFINE CLASS form1 AS form
    
    
    	Top = 0
    	Left = 0
    	Height = 129
    	Width = 291
    	DoCreate = .T.
    	Caption = "Form1"
    	Name = "Form1"
    	WindowType = 1
    
    	ADD OBJECT command1 AS commandbutton WITH ;
    		Top = 66, ;
    		Left = 96, ;
    		Height = 27, ;
    		Width = 96, ;
    		Caption = "Command1", ;
    		Name = "Command1"
    
    
    	ADD OBJECT combo1 AS combobox WITH ;
    		Height = 24, ;
    		Left = 96, ;
    		Top = 24, ;
    		Width = 100, ;
    		Name = "Combo1"
    
    
    	PROCEDURE Error
    		LPARAMETERS nError, cMethod, nLine
    		MESSAGEBOX("Form Error Event")
    	ENDPROC
    
    
    	PROCEDURE Init
    		ON ERROR MESSAGEBOX("On Error Message")
    	ENDPROC
    
    
    	PROCEDURE Unload
    		ON ERROR 
    	ENDPROC
    
    
    	PROCEDURE command1.Error
    		LPARAMETERS nError, cMethod, nLine
    		MESSAGEBOX("Command1 Error Event")
    		RETURN
    	ENDPROC
    
    
    	PROCEDURE command1.Click
    		thisform.combo1.Requery()
    	ENDPROC
    
    
    	PROCEDURE combo1.Requery
    
    		*!* this will throw an error and pass it on to
    		*!* the combo1 Error event.
    		TRY
    			this.AddListItem(.F.,1,1)
    		CATCH
    		ENDTRY
    		
    		*!* this will be handled by the TRY/CATCH block
    		TRY
    			ERROR 1
    		CATCH
    		ENDTRY	
    
    	ENDPROC
    
    	PROCEDURE combo1.Error
    		LPARAMETERS nError, cMethod, nLine
    		MESSAGEBOX("Combo1 Error Event")
    	ENDPROC
    
    ENDDEFINE
    *
    *-- EndDefine: form1
    **************************************************
    

     


    Thursday, December 29, 2011 3:43 PM

Answers

  • Look at the "Error Handler Priority" help topic. It says:

    Error takes precedence when:

    • An error occurs inside method code but outside a TRY block.

    • An error occurs in an object's method code, and the method is called directly or is called from another method, regardless of whether the method call appears inside or outside a TRY block.

    So, the behaviour described does fully follow the documentation of the product.

    The latest help is available at VFPX web: http://vfpx.codeplex.com/

    Update: VFP does not check method parameter data type in calling method, so the error really occurs in the called method. If you would call some system function with an invalid number of parameters then the error should be reported in the calling method (and also during code compilation). Parameter data types are always checked at run-time.
    Thursday, December 29, 2011 4:22 PM
    Moderator
  • The TRY - CATCH error trapping on the "thisform.r_oXMLAdapter.LoadXML(.F.)" command is correct.

    XMLAdapter class does not have any Error event, so the nearest possibility is the TRY - CATCH block around the call.

    VFP help also mentions this possibility:

    If the method call is in a TRY block, and no immediate Error event or method code exists for the object, Visual FoxPro searches for Error code inherited from the parent class or another class up the class hierarchy. If no Error code exists in the class hierarchy, Visual FoxPro looks for a CATCH block corresponding to the TRY block from which the method was called.

    Thursday, December 29, 2011 5:52 PM
    Moderator

All replies

  • 	PROCEDURE combo1.Requery
    
    		*!* this will throw an error and pass it on to
    		*!* the combo1 Error event.
    		TRY
    			this.AddListItem(.F.,1,1)
    		CATCH
    		ENDTRY
    		
    		*!* this will be handled by the TRY/CATCH block
    		TRY
    			ERROR 1
    		CATCH
    			 // Error Handling will be here because you are using try catch Combo1.Error not execute
    			MESSAGEBOX("Combo1 Error Event") 
    ENDTRY
    ENDPROC

    Please "Mark as Answer" if this post answered your question. :)

    Kalpesh Chhatrala | Software Developer | Rajkot | India

    Kalpesh 's Blog

    VFP Form to C#, Vb.Net Conversion Utility
    Thursday, December 29, 2011 3:57 PM
    Answerer
  • Yes, the second TRY/CATCH block is working as expected. Why does the first one not?
    Thursday, December 29, 2011 4:01 PM
  • Look at the "Error Handler Priority" help topic. It says:

    Error takes precedence when:

    • An error occurs inside method code but outside a TRY block.

    • An error occurs in an object's method code, and the method is called directly or is called from another method, regardless of whether the method call appears inside or outside a TRY block.

    So, the behaviour described does fully follow the documentation of the product.

    The latest help is available at VFPX web: http://vfpx.codeplex.com/

    Update: VFP does not check method parameter data type in calling method, so the error really occurs in the called method. If you would call some system function with an invalid number of parameters then the error should be reported in the calling method (and also during code compilation). Parameter data types are always checked at run-time.
    Thursday, December 29, 2011 4:22 PM
    Moderator
  • Hmm... I can't even override the AddListItem method like this:

     

    	PROCEDURE combo1.AddListItem
    		LPARAMETERS cItem, nItemID, nColumn
    		TRY
    			DODEFAULT(cItem, nItemID, nColumn)
    		CATCH
    		ENDTRY
    	ENDPROC

    That seems like a significant limitation with TRY/CATCH error handling.

    Now I know.

    Thanks.

    Thursday, December 29, 2011 4:41 PM
  • Below is another example. In my mind, given the quoted documentation, the LoadXML(.F.) call should not be handled by the TRY/CATCH and should throw an error. But it doesn't.

    Aren't both examples of the same thing?

      loFrm = CREATEOBJECT("form1")
     
      loFrm.Show
    
    
    **************************************************
    *-- Form:         form1 (c:\azb-tfs-vm\test\trycatchtest.scx)
    *-- ParentClass:  form
    *-- BaseClass:    form
    *-- Time Stamp:   12/29/11 10:25:05 AM
    *
    DEFINE CLASS form1 AS form
    
    
    	Top = 0
    	Left = 0
    	Height = 129
    	Width = 291
    	DoCreate = .T.
    	Caption = "Form1"
    	Name = "Form1"
    	WindowType = 1
    	r_oXMLAdapter = .NULL.
    
    	ADD OBJECT command1 AS commandbutton WITH ;
    		Top = 66, ;
    		Left = 96, ;
    		Height = 27, ;
    		Width = 96, ;
    		Caption = "Command1", ;
    		Name = "Command1"
    
    
    	ADD OBJECT combo1 AS combobox WITH ;
    		Height = 24, ;
    		Left = 96, ;
    		Top = 24, ;
    		Width = 100, ;
    		Name = "Combo1"
    
    
    	PROCEDURE Error
    		LPARAMETERS nError, cMethod, nLine
    		MESSAGEBOX("Form Error Event")
    	ENDPROC
    
    
    	PROCEDURE Init
    		ON ERROR MESSAGEBOX("On Error Message")
    		this.r_oXMLAdapter = CREATEOBJECT("xmladapter")
    	ENDPROC
    
    
    	PROCEDURE Unload
    		ON ERROR 
    	ENDPROC
    
    
    	PROCEDURE command1.Error
    		LPARAMETERS nError, cMethod, nLine
    		MESSAGEBOX("Command1 Error Event")
    		RETURN
    	ENDPROC
    
    
    	PROCEDURE command1.Click
    		thisform.combo1.Requery()
    		
    		*!* this is handled by the TRY/CATCH even though
    		*!* the error is in the XMLAdapter's method code
    		TRY 
    			thisform.r_oXMLAdapter.LoadXML(.F.)
    		CATCH
    		ENDTRY
    		
    	ENDPROC
    
    
    	PROCEDURE combo1.Requery
    
    		*!* this will throw an error and pass it on to
    		*!* the combo1 Error event.
    		TRY
    			this.AddListItem(.F.,1,1)
    		CATCH
    		ENDTRY
    
    		*!* this will be handled by the TRY/CATCH block
    		TRY
    			ERROR 1
    		CATCH
    		ENDTRY	
    
    	ENDPROC
    
    	PROCEDURE combo1.Error
    		LPARAMETERS nError, cMethod, nLine
    		MESSAGEBOX("Combo1 Error Event")
    	ENDPROC
    
    ENDDEFINE
    *
    *-- EndDefine: form1
    **************************************************
    

    Thursday, December 29, 2011 5:07 PM
  • Yes, the invalid parameter data type error occurs on the LPARAMETERS command (or even before) which cannot be inside the TRY - CATCH block.

    I don't see this behavior as a major limitation because this kind of error is rather design problem than something which should happen during the program run. TRY - CATCH should be used for run-time erros trapping namely.

    You may also create your own method:

    PROCEDURE combo1.AddListItemWithParamCheck
    	LPARAMETERS cItem, nItemID, nColumn
    	TRY
    		IF VARTYPE(cItem) <> "C" OR ;
    		(PCOUNT()>1 AND VARTYPE(nItemID)<> "N") OR ;
    		(PCOUNT()>2 AND VARTYPE(nColumn)<> "N")
    			ERROR 11
    		ENDIF
    		This.AddListItem(cItem, nItemID, nColumn)
    	CATCH
    		*-- Error handling
    	ENDTRY
    ENDPROC
    

    I would say to code for such a highg level of safety is contraproductive. We (VFP developers) all know FoxPro does not support strong data typing and we are rather focussed to utilize this feature as a product advantage than to mark it as a limitation.

    Thursday, December 29, 2011 5:16 PM
    Moderator
  • The TRY - CATCH error trapping on the "thisform.r_oXMLAdapter.LoadXML(.F.)" command is correct.

    XMLAdapter class does not have any Error event, so the nearest possibility is the TRY - CATCH block around the call.

    VFP help also mentions this possibility:

    If the method call is in a TRY block, and no immediate Error event or method code exists for the object, Visual FoxPro searches for Error code inherited from the parent class or another class up the class hierarchy. If no Error code exists in the class hierarchy, Visual FoxPro looks for a CATCH block corresponding to the TRY block from which the method was called.

    Thursday, December 29, 2011 5:52 PM
    Moderator
  • Thanks for the great explanations Pavel.
    Thursday, December 29, 2011 6:07 PM