TRY/CATCH routine: Is FINALLY is mandatory in version before 9.0?

[Rajesh Karunakaran]

Hi all,

My client getting TRY/CATCH mismatch error in one program. Its a program where we convert a DBF to XLSX using the "VfpXworkbookXLSX" library. When I run at my end I don't come across that in spite of trying with various scenarios. Too, apparently I am not able to find anything wrong in the code. The only thing I see is that I have not included the 'FINALLY' section within the TRY...CATCH routine. I am not sure which Vfp version he's using. Also, my client calls this program from another program. I am not sure if there is a TRY/CATCH in that calling program.

Just to try, I am going to give him the edited version with the FINALLY added in all TRY/CATCH.

Anyway, is the 'FINALLY' section mandatory in Vfp version before 9.0?

Rajesh

 

[Scott24x7]

No, FINALLY is like OTHERWISE in a case statement (sort of).
But no, it's not "mandatory. Only TRY ENDTRY is mandatory, everything else is optional.

 

[Rajesh Karunakaran]

Thank you Scott.
Okay, so I will now need to check deeper why he's getting that problem.

 

[Chris Miller]

It's true, even catch isn't mandatory, but you fail to catch an error, if you do something like

try
use hkjsdhkdhgdf
endtry

This is executed, but as it does not find a file hkjsdhkdhgdf.dbf throws this error message:

So CATCH is mandatory, too. Not from the technical perspective, but when you use TRY you use it to catch an error and handle it with very specific, local code handling some expected errors, not as general error handling. This is essentially the error message stated after "Message:" but nested within the error of an "Unhandled Structured Exception" because the CATCH is missing. So indirectly it is pointing out that CATCH is mandatory.

Anyway, it's not a TRY/CATCH mismatch.

I think a TRY CATCH mismatch is pointing out that you have wrong nesting of code, like beginng an IF..ENDIF before TRY, but have the ENDIF before CATCH:

If Seconds()<3600
    Use x
    Try
        Locate Y=2
    Endif
Catch
    *
Endtry

This doesn't do it, I get the error 1211: An IF | ELSE | ENDIF statement is missing.

​

But the construct has to be something similar, wrong nesting of TRY with other nested code
You can see as this is beautified code (indented) that TRY is indented, while CATCH and ENDTRY are not, they are on the level of the IF, instead, as if there is an IF..CATCH,,ENDTRY construct.

That would also cover things like DO CASE...ENDCASE, FOR loops, WITH..ENDWITH etc. etc.
Regarding this, you can have a TRY..ENDTRY within IF, but the ENDTRY has to be before the ENDIF. When the IF has an ELSE branche, the TRY could also be after the ELSE, but a TRY in the IF branch has to have the ENDTRY before the ELSE, otherwise you'll just mess up the code structure. You can easily see such things, when you beautify your code.

 

[Mike Lewis]

For what it's worth, I almost never use FINALLY in a TRY/CATCH. It's certainly not mandatory.

But there are other limitations on what you can and cannot do with in a TRY/CATCH/FINALLY. For example, issuing a RETURN. Take a look at the "Structured Error Handling" Help topic for more information.

Mike

 

[Mike Lewis]

I disagree with Chris re whether CATCH is mandatory. I occasionally wrap code in a TRY/ENDTRY when I don't need to handle the error if the code fails. One example would be:

TRY
  USE Table1 EXCLUSIVE
  PACK

  USE TABLE 2 EXCLUSIVE
  PACK

  etc.
ENDTRY

Here, I want to pack the tables, but only if I can get exclusive use. If I can't get exclusive use of a particular, it doesn't matter. I just skipping the packing of that table (until the next time).

Of course, this sort of case if fairly rare. For most of the time, you would never do TRY/FINALLY without a CATCH.

(None of this answers your question, of course.)

Mike

 

[Rajesh Karunakaran]

Dear all,
I think that particular error comes up when we don't have a ENDTRY after the CATCH.

TRY
    =MYPRG("PARAM1")  && This PRG has TRY/CATCH and it works fine.
CATCH

Now, when MYPRG exits, it gives the mismatch error.

So, let me check with my client, if his calling program has a wrong TRY/CATCH routine.

 

[Scott24x7]

If you don't have an ENDTRY you should be getting a compiler error.
It's like having an IF without an ENDIF or a CASE without and ENDCASE.

There is no such thing as an implicit ENDTRY.

 

[Chris Miller]

Interesting, Mike,
But it does work as I showed with my example and creates an error nested within an Unhandled Structured Exception error. If you have a general ON ERROR routine the error arrives in that handling. So, when I prepare a situation a DBF is used already and can't get used in a second VFP session exclusive I get the error you want to supress.

If you don't want to handle the error and just suppress it, just have a CATCH branch that's empty, but I'd never skip CATCH. WIthout CATCH it just works as if not having TRY..ENDTRY at all.

Rajesh, that aside, nice you found that a missing ENDTRY causes the TRY/CATCH mismatch. The closing of a TRY has always to be ENDTRY, even though it's common to talk about TRY..CATCH, the help also refers to it as TRY..ENDTRY.

It doesn't depend on calling something from the TRY block. You get a "TRY/CATCH/FINALLY/ENDTRY mismatch or error" message when you omit the ENDTRY.

 

[Mike Lewis]

Chris, re your point about an empty CATCH. Looking back over my PACK routine, I do have an empty CATCH in some of those cases. But, as far as I can see, it doesn't invoke the default error-handler when the CATCH is empty. (I'm not sure about that. Let me check.)

Mike

 

[Mike Lewis]

OK, I need to clarify what I wrote before:

If you have a TRY/ENDTRY without a CATCH, an "Unstructured error" occurs, regardless of whether there is an actual error..

If you have an empty CATCH, any error is ignored. (This is the case with my packing routine.)

This doesn't explain the behaviour that Rajesh is seeing. but I thought it worth clarifying.

Mike

 

[GTGeek88]

OK, I need to clarify what I wrote before:

If you have a TRY/ENDTRY without a CATCH, an "Unstructured error" occurs, regardless of whether there is an actual error..

If you have an empty CATCH, any error is ignored. (This is the case with my packing routine.)

This doesn't explain the behaviour that Rajesh is seeing. but I thought it worth clarifying.

Mike

Yeah, for me it's always:

Try
    <CodeHere>
Catch
    *No action needed
EndTry

 

[Rajesh Karunakaran]

Rajesh, that aside, nice you found that a missing ENDTRY causes the TRY/CATCH mismatch. The closing of a TRY has always to be ENDTRY, even though it's common to talk about TRY..CATCH, the help also refers to it as TRY..ENDTRY.

Yes Chris, when many people mention it like TRY/CATCH, it's more onto the purpose than to the syntax!

 

[ggreen61]

Hello--

I wrote the class VfpXworkbookXLSX. In this class I have TRY-ENDTRY where the CATCH will THROW the error to a higher TRY-ENDTRY. This was done to allow for errors to be caught at a higher level and exit the class gracefully. Possibly, one of the THROW statements is not being caught as expected. You might wrap your usage of the class in a TRY-ENDTRY. If this solves the problem, please let me know where the THROW is coming from by looking at the CATCH TO loException object and giving me the code line reference.