Recent

Author Topic: What is good in using try..finally?  (Read 17756 times)

MarkMLl

  • Hero Member
  • *****
  • Posts: 3467
Re: What is good in using try..finally?
« Reply #90 on: October 10, 2021, 09:23:54 am »
Neither OOP itself, nor the way the fpc compiler handles it, introduce any such force.
That statement is valid only if properties are not considered part of OOP, which is something some participants in this thread claim.  A claim that I consider "unconvincing".

A unit can have properties, therefore the set of (languages with properties) can- potentially at least- be larger than the set of (languages with OOP).

Apart from that I reiterate my position: the fact that Object Pascal is used in a way that encourages the use of exceptions could arguably be interpreted as a flaw in the language design, but a flaw in one language's design cannot be interpreted as a flaw in the overall OOP concept.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

MarkMLl

  • Hero Member
  • *****
  • Posts: 3467
Re: What is good in using try..finally?
« Reply #91 on: October 10, 2021, 09:39:21 am »
I want to say that I still consider this a bug in the RTL. SetJmp/LongJmp not handling the exception state transparently means that they simply can not be used with exceptions. In C++, which also supports SetJmp/LongJmp as well as exceptions this isn't a case and these functions handle the exception state for you.

I'm trying to think back. When I was doing really low-level microkernel stuff on protected-mode x86 I postprocessed the binaries to associate far calls with call gates and coroutine operations with task transfers: my recollection is that I had absolutely no need for far jumps.

It might even be defensible to argue that with exceptions for gross error recovery and a decent coroutine implementation SetJmp/LongJmp could be removed from the language.

Quote
Lastly I want to repeat what I've wrote a little bit earlier. Try-finally should not only be associated with exceptions. I think is a little bit because the naming (i.e. having the "try" part), but try-finally is much more than that. In fact even without exceptions try-finally would be massively useful.

Which is why when discussing such things outside the context of specific syntax I usually refer to start/finally.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

MarkMLl

  • Hero Member
  • *****
  • Posts: 3467
Re: What is good in using try..finally?
« Reply #92 on: October 10, 2021, 09:42:49 am »
In order to use try..exception/try..finally it is necessary to include the called code in them (which usually happens in OOP). And in my code, I'm not checking the included code, but the final result. And, I can't use these methods for verification because they won't "try" to do. Everything is already done and there is nothing left to process. The mistake has already been made (something is my fault here, and I didn't understand it initially).

Therefore, we need to look at what is happening. If a procedure/function is called, then it can be handled in a similar way. It will try to work, raise an exception and return (pretending that the code did not work). And then we will bypass the error. If we process the final result, we will not be able to process anything with these methods.

That doesn't quite make sense. If you have problems in that area, I suggest it would be worth starting a separate thread and posting an example.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

y.ivanov

  • Sr. Member
  • ****
  • Posts: 306
Re: What is good in using try..finally?
« Reply #93 on: October 10, 2021, 11:05:04 am »
Should I know why? No, I shouldn't. I am a novice, please explain, why?
In that case, I recommend you read the book "Oh Pascal" by Doug Cooper.  Excellent book, it will answer that question for you and many more. Good reading for a novice.
Thank you for the recommendation. This is a good book, indeed.

Now, I want to quote Mr.Cooper from that book, the excerpt is from "Appendix: Everything You Wanted To Know About Pascal", p.553 in my copy:
Quote
There are also extraordinary circumstances in which using gotos is permissible. Most common is the ‘I want to get out of here in a hurry’ case. Suppose, for example, that program input is coming from punched cards or tape, and an input checking procedure spots incorrect data. Since we know that there’s no point in continuing to process input, we can issue an error message and go to the very end of the program (because it’s o.k. to label an end).

  (code example)

The goto is also properly used for beating a hasty retreat from a function whose arguments are determined to be inappropriate. In these cases the desirability of graceful degradation outweighs the stigma attached to using gotos.
It doesn't prove your point, just on the contrary! It justifies goto in the case of error.

I'm definitely guilty of expecting the skeptics of OOP/exceptions to know Object Pascal and be aware of collections among other things.  I guess my expectations are misplaced.
Considering that collections such as TString are not part of the language definition, knowing or not knowing about them is not a reflection on an individual's knowledge of Object Pascal. 
You continue insisting that OOP implementation in Object Pascal forces using of "try-except" based only on the language specification? How you can do that without knowing a bit of RTL/FCL/LCL (and hence confusing OOP with the framework)? It is like to say that the sole existence of parameter-less functions in Pascal (as somebody already noted this earlier) is forcing you to do the same.


   

440bx

  • Hero Member
  • *****
  • Posts: 2547
Re: What is good in using try..finally?
« Reply #94 on: October 10, 2021, 11:54:06 am »
It doesn't prove your point, just on the contrary! It justifies goto in the case of error.
It does not in any way do that.  The reason he included that _exception_ about the use of goto is because there is no "exit" and other control flow facilities in the Pascal definition he is using and, you know that.

You continue insisting that OOP implementation in Object Pascal forces using of "try-except" based only on the language specification? How you can do that without knowing a bit of RTL/FCL/LCL (and hence confusing OOP with the framework)? It is like to say that the sole existence of parameter-less functions in Pascal (as somebody already noted this earlier) is forcing you to do the same.
IOW, no one can tell that an elephant is big and heavy unless they are a veterinarian.  It's a fact that when using the Pascal implementation of OOP, particularly the Delphi and FPC implementations, the programmer will be forced to use "try-except" in many cases where they should not be necessary. 
FPC v3.0.4 and Lazarus 1.8.2 on Windows 7 64bit.

MarkMLl

  • Hero Member
  • *****
  • Posts: 3467
Re: What is good in using try..finally?
« Reply #95 on: October 10, 2021, 12:19:00 pm »
It does not in any way do that.  The reason he included that _exception_ about the use of goto is because there is no "exit" and other control flow facilities in the Pascal definition he is using and, you know that.

Having said which (and by now I'm not sure whether I'm pouring oil onto troubled water or onto the fire) I've been at a conference where exit/break and so on were criticised as being "closet gotos" so as such were to be derided. I can't remember whether the proponent of that idea had ever done any real work...

I will, again, repeat Dijkstra's position:

Quote
Please don't fall into the trap of believing that I am terribly dogmatical about [the goto statement]. I have the uncomfortable feeling that others are making a religion out of it, as if the conceptual problems of programming could be solved by a single trick, by a simple form of coding discipline!

I think that my position has to be that while it is always satisfying to be able to simplify an idiom, which would suggest that from the user's POV start/finally and try/except should be collapsed into a single language structure, in practical terms it's probably desirable for idioms which have vastly different runtime behaviour to be kept distinct because that (as an hypothetical example) would enable the FPC maintainers to fix the problems highlighted by Warfley by modifying the cross-frame try/except behaviour without impacting on the intra-frame start/finally.

And that allows me to propose a succinct response to OP's question: if what you're doing is strictly intra-frame (i.e. doesn't leave the current procedure/function) then you don't use try/except, since that introduces a great deal of unneeded runtime complexity and overhead.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

Thaddy

  • Hero Member
  • *****
  • Posts: 10991
Re: What is good in using try..finally?
« Reply #96 on: October 10, 2021, 12:24:15 pm »
Well, let's introduce:
Code: Pascal  [Select][+][-]
  1. try
  2.    //
  3. Fatally
  4.  
  5. // end part can not be reached....

Bit of a sick conversation, all this. One of the "finest".....
try/finally is mis-used, but simply resource protection. NOTHING else. And GOOD.
try/except is even more mis-used but satisfies its design. And even more misunderstood: exception should be used for unpredicatble code paths by programmers -, not the predectable ones: those should be trapped in your code. Predicatble exceptions? Go back to school.
« Last Edit: October 10, 2021, 12:34:02 pm by Thaddy »
The average programmer productivity is 4-5 hours per day. Peak performance 72 hours for short bursts. MTBF is 1 second or less.

y.ivanov

  • Sr. Member
  • ****
  • Posts: 306
Re: What is good in using try..finally?
« Reply #97 on: October 10, 2021, 12:40:58 pm »
There were a hints that conversation was leading nowhere...
At least I've learned a Welsh word that sounds amazingly like a word from my language with the same meaning.

MarkMLl

  • Hero Member
  • *****
  • Posts: 3467
Re: What is good in using try..finally?
« Reply #98 on: October 10, 2021, 12:56:29 pm »
There were a hints that conversation was leading nowhere...
At least I've learned a Welsh word that sounds amazingly like a word from my language with the same meaning.

In some renditions it stands for Traditional Welsh Protestant :-)

In any event, I think this discussion has departed a long way from answering OP's question.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

jollytall

  • Full Member
  • ***
  • Posts: 122
Re: What is good in using try..finally?
« Reply #99 on: October 10, 2021, 07:56:18 pm »
In any event, I think this discussion has departed a long way from answering OP's question.

Yes, but I really enjoyed reading it. Also I learnt a lot, as I also summarized above.

Two quick reactions:

That said, even this is not inherent to OOP in any shape or form. This is just how it was chosen to implement Classes in Object Pascal. This could easiely be changed by having the ability to set the return value of the constructor manually rather than automatically.
Other languages like C++, which allow for their classes to be stack allocated, don't run into that problem.
Although not said explicitly, it sounds as FPC classes were pascal OOP and comparable to C++ classes, and this comparison leads to points like stack vs. heap. Important to mention that classes is not core OOP (at least in my eyes) even in pascal. You can always use object instead of class and that behaves much more similar to C++ class, can be in stack, etc.
Obviously, if you want to use Lazarus components, those are classes, but you do not have to use them and you can still use OOP. This leads to my second point.

Writing code without try..except, try..finally or even without lcl, without classes, etc. is absolutely possible. I can also agree that with sufficient knowledge and effort the resulting asm can be as good or even better, smaller, faster than these more complex structures.
I remember I wrote a program in pure Z80 assembler some 40 years ago. That was small (had to be, as the total RAM was 48Kb) and efficient but took me weeks to write. Today I could write the same in an hour using modern tools.
Also I remember even in Delphi first I made Windows GUI applications calling Windows API calls directly. Again it worked, but then Forms, and other components made it much simpler, faster.
I feel the same discussion around try now. I see it as a huge productivity gain if used smartly. If we spend only half of the time saved on testing the result, probably we will have a better code than doing everything ourselves without it.

MarkMLl

  • Hero Member
  • *****
  • Posts: 3467
Re: What is good in using try..finally?
« Reply #100 on: October 10, 2021, 09:49:27 pm »
In any event, I think this discussion has departed a long way from answering OP's question.

Yes, but I really enjoyed reading it. Also I learnt a lot, as I also summarized above.

Thanks for the feedback on that, IMO it's really quite important particularly when the community starts wibbling.

Thinking about your point about being able to avoid start/finally and try/except:

In the first case, I think it's good style to be able to write something like

Code: Pascal  [Select][+][-]
  1.   Open(something);
  2.   try
  3. ... do stuff here
  4.   finally
  5.     Close(something)
  6.   end;
  7.  

Now in practical terms the "do stuff here" might be trivial and not likely to cause problems, but that layout still draws ones eye to the fact that the file (or whatever) is being explicitly closed.

In the second case: I've got a lot of code based on a compiler-compiler originally published in '64. My first implementation of that was in about '86, and the only way to implement the abend specified by the algorithm (which proceeded to produce error messages showing what had gone wrong where) was by using a setjmp/longjmp (this was back in the days of MT+86 and the earliest versions of Turbo Pascal). But that code translated surprisingly easily to use an exception when the facility became available (i.e. using conditional defines), which had the advantage that problems could be directed to a code fragment which hadn't yet been touched by execution: the error handling became purely defined by the syntax of the program, rather than by the runtime control flow.

So as I've said already: exceptions shouldn't be overused, and that's particularly the case when they are likely to go via the OS. But they have their uses.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

Warfley

  • Hero Member
  • *****
  • Posts: 600
Re: What is good in using try..finally?
« Reply #101 on: October 11, 2021, 01:03:12 am »
It might even be defensible to argue that with exceptions for gross error recovery and a decent coroutine implementation SetJmp/LongJmp could be removed from the language.
I would agree but personally I like these really academic and experimental projects which sometimes require you getting "dirty" and often require such low level functions. So while in productive code i don't think that such jumps are required, I wouldnt like taking them away

 

TinyPortal © 2005-2018