>>>AFAIK its use would have been optional, so no-one was being forced to use it. It seems to me at least some people thought it would be worthwhile. Are you saying it was completely redundant and/or useless?
>>
>>I am saying I didn't like it in VFP and C#, and glad it didn't get into Go as well.
>>
>>Some might like it but then it would prevent the search for a better error handling investigation. On that issue page, there were already many good and solid points why it shouldn't get into the language.
>
>I often feel like walking in swamp when encountering special error code - even if I coded part of it ;-)
>
>My personal standards are:
>vfp class based error handling sounded great on first read, but in reality was less useful. I try to avoid it now.
>
>There *should* be an excellent global error handler describing program state in the event of user crash - this helps later debug.
>
>Do NOT bracket everything inside TRY CATCH, but use it most of the time ONLY when actively debugging/aware of a specific issue
>When you think you fixed all possible errors at that place, delete TRY/CATCH again.
>
>Do NOT attempt to keep the program running after an error as basic strategy - perhaps for a small number of situations encountered, but unable to debug or fix. If so, handling the error with TRY/CATCH locally is cleaner than in global error code, even better is checking with normal code in a loop before error can manifest.
>
>So having TRY/CATCH in the language is fine with me, (often) reading it in code is a marker for tasks not finished or an undisciplined/murky thinking coder ;-)
>It is much better compared to:

>**** I have to fix this
>

>my 0.02€
>
>thomas

I didn't mean "I have to fix this" :)

Go has defer and a good error handling already.

I really don't like try..catch..finally (not in VFP, nor in C#).

VFP's own old error handler is much better IMHO.