I would disagree with all my respect. You can of course run some code that you may have issues with and continue linear execution if an error occurs. There isn't any issue in managing it.
As I said, "personally", everyone is on his own. I prefer ON ERROR.
>Without try/catch there's no way to run some code that you know you may have issues with and continue linear execution if an error occurs. The big issue is keeping the call context and scope of variables when you leave the linear code execution stack.IOW, you can localize error handling which was really difficult to do previously or at least not without introducing another call stack level of another function to execute. And with ON ERROR you have to make sure you properly reset the ON ERROR handler each step of the way - if that doesn't happen who knows where errors go...
>
>I struggled with this crap for years in Web Connection and the only flawed solution there was to `RETURN TO method` which to make things worse was very flakey. Using TRY/CATCH allowed for localizing errors to each specific scope of the application - such as Web Connection process classes, or server errors at the server level and finally letting completely unhandlable errors bubble up to the top level TRY/CATCH. It also allows capturing errors in initilization in COM objects which otherwise wouldn't be possible (no OnError() handlers until objects are instantiated) and ON ERROR can't do anything useful other than ignore errors inside
>
>+++ Rick ---
>
>>Yes seriously. I know how to use Try\catch and I still find it less powerful than ON ERROR. Not all other good languages use try\catch to handle errors, some do. For example take golang. It has a very good error handling, yet it doesn't use try\catch (and is much newer language than C#).
>>As you say there are cases it cannot catch but ON ERROR does.
>>
>>I don't understand what you mean by saying "Prior to TRY/CATCH there was no support for isolating code in FoxPro".
>>
>>As said "personally". Everyone is on his own.
>>
>>
>>>
>>>Wow, seriously? :-)
>>>
>>>Try catch to me is one of the most important updates in FoxPro that provides sanity to error handling. If you want 'global' error handling with Try/Catch you can just define a TRY/CATCH block at the top of your call stack in your startup code and you still get a global error handler effectively. There are a few edge cases, but you can then **still** use a ON ERROR handler to handle those extra cases.
>>>
>>>Prior to TRY/CATCH there was no support for isolating code in FoxPro - the closest thing was a class level error handler which is not granular enough and effectively asynchronous which makes it very hard to continue after errors. TRY/CATCH lets you easily handle an error and take a specific action (or not) and continue.
>>>
>>>It doesn't hurt that just about every other language supports TRY/CATCH like constructs so once you get familiar with it it'll be useful for other languages as well.
>>>
>>>+++ Rick ---
>>>
>>>
>>>
>>>>>Hi,
>>>>>
>>>>>Do I understand correctly that if there is an error (typo or undeclared variable or whatever problem) within TRY/CATCH, the global ON ERROR DO MyErrorHandler() will catch it? That is, that TRY/CATCH is not "isolated" from the global error handling.
>>>>>Please let me know if I am correct. Or, if I don't understand it correctly.
>>>>>
>>>>>TIA.
>>>>
>>>>You understood it wrong. A Try/Catch isolates the error from outside block (silences the error if you do nothing in CATCH). You can make the error available to outside block by using THROW in catch. ie:
>>>>
>>>>
>>>>On Error Do errHandler
>>>>Try
>>>> ? "A"+15
>>>>Catch To oErr
>>>> * m.oErr.UserValue = "Error caught with catch."
>>>> Throw
>>>>* Throw "Error caught with catch."
>>>>Endtry
>>>>? m.newVar
>>>>On Error
>>>>
>>>>Procedure errHandler
>>>> ? "Error: [["+Message()+"]]"
>>>>Endproc
>>>>
>>>>
>>>>PS: Personally I prefer using On Error. Try Catch is not as powerful IMHO, doesn't catch every error that ON ERROR catches for example.
