On 2024-01-29, Dave Froble <davef@tsoft-inc.com> wrote:
> On 1/29/2024 8:24 AM, Simon Clubley wrote:
>>
>> $ set response/mode=good_natured
>>
>> Don't be too hard on David, Dan. He still likes to use line numbers
>> in his BASIC code... :-)
>>
>
> That is a filthy slander ...
>
> Line numbers can be used in place of labels for GoTo statements, which you'll
> also probably also slander. But they can be useful. Other than that, line
> numbers can be useful for appending boiler plate code to a program. Line
> numbers are used in handling error exceptions and handling.
>
> Your implication that I use numbers on every line is just false.
>

$ set response/mode=good_natured

Er, David, where do I say _every_ line ? Or is that a guilty conscience
that's reading something above which isn't there ? :-)

It was a reference to the last time you posted a bit of BASIC code and
it was pointed out it could be written much more cleanly using structured
control loops.

Someone (Arne IIRC) posted some BASIC code using structured control
loops and I don't remember you being too impressed by the different
coding style, even though to me, Arne's version looked a lot cleaner.

> If I'm going to have:
>
> On Error GoTo 32000
>
> Ahhh, what's the use, you're probably just laughing ...
>

$ set response/mode=angry

On the plus side, and to take the opportunity to vent my anger at something
that I get more angry about whenever more details are revealed, at least
you know how to reverse the sign of a variable without having to write a
function to do it. :-( :-(

See:

https://news.ycombinator.com/item?id=38926582

Original reference:

https://www.postofficehorizoninquiry.org.uk/evidence/fuj00080690-report-eposs-pinicl-task-force

See page 17 onwards of the PDF. :-(

Innocent people went to jail because of the system this code is
a part of, and because of the coverup around it, and it took
a TV drama to really get things moving. :-(

So, yes, I may make fun of your line numbers, but at least you most
certainly know what you are doing, unlike the above people.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 1/29/2024 1:27 PM, Simon Clubley wrote:
> On the plus side, and to take the opportunity to vent my anger at something
> that I get more angry about whenever more details are revealed, at least
> you know how to reverse the sign of a variable without having to write a
> function to do it. :-( :-(
>
> See:
>
> https://news.ycombinator.com/item?id=38926582
>
> Original reference:
>
> https://www.postofficehorizoninquiry.org.uk/evidence/fuj00080690-report-eposs-pinicl-task-force
>
> See page 17 onwards of the PDF. :-(
>
> Innocent people went to jail because of the system this code is
> a part of, and because of the coverup around it, and it took
> a TV drama to really get things moving. :-(
>
> So, yes, I may make fun of your line numbers, but at least you most
> certainly know what you are doing, unlike the above people.

The code is VB6.

But none of the problems are Basic specific. It is possible
to write the same bad code in C or Fortran or whatever.

So it just shows that there are some really really bad programmers out
there.

Arne

PS: Good compilers may have detected the unreachable code. But it
is still good vs bad compiler not good vs bad language.

=?UTF-8?Q?Arne_Vajh=C3=B8j?= <arne@vajhoej.dk> wrote:
>The code is VB6.
>
>But none of the problems are Basic specific. It is possible
>to write the same bad code in C or Fortran or whatever.
>
>So it just shows that there are some really really bad programmers out
>there.

I have worked with people who could write spaghetti Fortran in any
programming language available. Did you know that LISP has a goto?
It does.

>PS: Good compilers may have detected the unreachable code. But it
> is still good vs bad compiler not good vs bad language.

The exciting part is when they tell you not to remove the unreachable code,
because the program crashes at runtime when you do that.
--scott

On 30 Jan 2024 00:50:47 -0000, kludge wrote:

> Did you know that LISP has a goto?

Scheme doesn’t. It has continuations, which are a cool thing that can be
used to implement control structures, exceptions and coroutines, yet make
it quite difficult to express arbitrary gotos. Win-win, really.

On 1/29/2024 7:50 PM, kludge@panix.com wrote:
> =?UTF-8?Q?Arne_Vajh=C3=B8j?= <arne@vajhoej.dk> wrote:
>> The code is VB6.
>>
>> But none of the problems are Basic specific. It is possible
>> to write the same bad code in C or Fortran or whatever.
>>
>> So it just shows that there are some really really bad programmers out
>> there.
>
> I have worked with people who could write spaghetti Fortran in any
> programming language available.

"A real Fortran programmer can write Fortran in any language"

Every time this comes up I post this Fortran/Pascal code:

PROGRAM GOTOFUN(INPUT,OUTPUT);
LABEL L731,L113,L247,L588,L761,L922,L399,L601;
VAR LBL:INTEGER;
VAR I:INTEGER;
BEGIN
L731: GOTO L113;
LBL:=399;
L113: I:=0;
WRITELN(I);
L247: LBL:=601;
IF(I<0)THEN GOTO L588 ELSE IF(I=0)THEN GOTO L922 ELSE GOTO L399;
L588: I:=I+1;
WRITELN(I);
GOTO L399;
L761: CASE(LBL)OF 399: GOTO L399; 601: GOTO L601; END;
L922: I:=I+1;
WRITELN(I);
CASE(I)OF 1: GOTO L588; 2: GOTO L399; 3: GOTO L922; END;
L399: GOTO L761;
L601: END.

:-)

Arne

On 1/29/2024 8:02 PM, Arne Vajhøj wrote:
> On 1/29/2024 7:50 PM, kludge@panix.com wrote:
>> =?UTF-8?Q?Arne_Vajh=C3=B8j?= <arne@vajhoej.dk> wrote:
>>> The code is VB6.
>>>
>>> But none of the problems are Basic specific. It is possible
>>> to write the same bad code in C or Fortran or whatever.
>>>
>>> So it just shows that there are some really really bad programmers out
>>> there.
>>
>> I have worked with people who could write spaghetti Fortran in any
>> programming language available.
>
> "A real Fortran programmer can write Fortran in any language"
>
> Every time this comes up I post this Fortran/Pascal code:
>
> PROGRAM GOTOFUN(INPUT,OUTPUT);
> LABEL L731,L113,L247,L588,L761,L922,L399,L601;
> VAR LBL:INTEGER;
> VAR I:INTEGER;
> BEGIN
> L731: GOTO L113;
> LBL:=399;
> L113: I:=0;
> WRITELN(I);
> L247: LBL:=601;
> IF(I<0)THEN GOTO L588 ELSE IF(I=0)THEN GOTO L922 ELSE GOTO L399;
> L588: I:=I+1;
> WRITELN(I);
> GOTO L399;
> L761: CASE(LBL)OF 399: GOTO L399; 601: GOTO L601; END;
> L922: I:=I+1;
> WRITELN(I);
> CASE(I)OF 1: GOTO L588; 2: GOTO L399; 3: GOTO L922; END;
> L399: GOTO L761;
> L601: END.
>
> :-)
>
> Arne
>

I'm amused every time the GoTo bashing begins.

Not only is there nothing wrong when using a branch operation, when appropriate,
just look at the assembler listings after compilation. Branching is just about
all assembler does, as required.

Now, I won't defend what I and most consider improper use of the poor
misunderstood GoTo statement.

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On 30/01/2024 07:06, Dave Froble wrote:
> On 1/29/2024 8:02 PM, Arne Vajhøj wrote:
>> On 1/29/2024 7:50 PM, kludge@panix.com wrote:
>>> =?UTF-8?Q?Arne_Vajh=C3=B8j?=  <arne@vajhoej.dk> wrote:
>>>> The code is VB6.
>>>>
>>>> But none of the problems are Basic specific. It is possible
>>>> to write the same bad code in C or Fortran or whatever.
>>>>
>>>> So it just shows that there are some really really bad programmers out
>>>> there.
>>>
>>> I have worked with people who could write spaghetti Fortran in any
>>> programming language available.
>>
>> "A real Fortran programmer can write Fortran in any language"
>>
>> Every time this comes up I post this Fortran/Pascal code:
>>
>>       PROGRAM GOTOFUN(INPUT,OUTPUT);
>>       LABEL L731,L113,L247,L588,L761,L922,L399,L601;
>>       VAR LBL:INTEGER;
>>       VAR I:INTEGER;
>>       BEGIN
>> L731: GOTO L113;
>>       LBL:=399;
>> L113: I:=0;
>>       WRITELN(I);
>> L247: LBL:=601;
>>       IF(I<0)THEN GOTO L588 ELSE IF(I=0)THEN GOTO L922 ELSE GOTO L399;
>> L588: I:=I+1;
>>       WRITELN(I);
>>       GOTO L399;
>> L761: CASE(LBL)OF 399: GOTO L399; 601: GOTO L601; END;
>> L922: I:=I+1;
>>       WRITELN(I);
>>       CASE(I)OF 1: GOTO L588; 2: GOTO L399; 3: GOTO L922; END;
>> L399: GOTO L761;
>> L601: END.
>>
>> :-)
>>
>> Arne
>>
>
> I'm amused every time the GoTo bashing begins.
>
> Not only is there nothing wrong when using a branch operation, when
> appropriate, just look at the assembler listings after compilation.
> Branching is just about all assembler does, as required.
>
> Now, I won't defend what I and most consider improper use of the poor
> misunderstood GoTo statement.
>

But unless used very carefully, it can create horrible spaghetti like
code, and is also easy to screw up.

Using proper structured constructs is much better - easier to read as
well, hence better maintainability.

--
Chris

On 1/29/2024 7:50 PM, kludge@panix.com wrote:
> =?UTF-8?Q?Arne_Vajh=C3=B8j?= <arne@vajhoej.dk> wrote:
>> The code is VB6.
>>
>> But none of the problems are Basic specific. It is possible
>> to write the same bad code in C or Fortran or whatever.
>>
>> So it just shows that there are some really really bad programmers out
>> there.
>
> I have worked with people who could write spaghetti Fortran in any
> programming language available. Did you know that LISP has a goto?
> It does.
>
>> PS: Good compilers may have detected the unreachable code. But it
>> is still good vs bad compiler not good vs bad language.
>
> The exciting part is when they tell you not to remove the unreachable code,
> because the program crashes at runtime when you do that.

Many moons ago I had to try to fix a number of programs that
crashed whenever run. Back in those days a common method was
to add statements to display variables during execution. I
had many cases where adding those statements made the program
work.

bill

On 30/01/2024 16:45, bill wrote:
> On 1/29/2024 7:50 PM, kludge@panix.com wrote:
>> =?UTF-8?Q?Arne_Vajh=C3=B8j?=  <arne@vajhoej.dk> wrote:
>>> The code is VB6.
>>>
>>> But none of the problems are Basic specific. It is possible
>>> to write the same bad code in C or Fortran or whatever.
>>>
>>> So it just shows that there are some really really bad programmers out
>>> there.
>>
>> I have worked with people who could write spaghetti Fortran in any
>> programming language available.  Did you know that LISP has a goto?
>> It does.
>>
>>> PS: Good compilers may have detected the unreachable code. But it
>>>      is still good vs bad compiler not good vs bad language.
>>
>> The exciting part is when they tell you not to remove the unreachable
>> code,
>> because the program crashes at runtime when you do that.
>
> Many moons ago I had to try to fix a number of programs that
> crashed whenever run.  Back in those days a common method was
> to add statements to display variables during execution.  I
> had many cases where adding those statements made the program
> work.
>
> bill

Could it have been the variables were being incorrectly being optimised
out, but adding a print statement would avoid that. I have seen that a
few times

--
Chris

On 1/30/2024 12:14 PM, Chris Townley wrote:
> On 30/01/2024 16:45, bill wrote:
>> On 1/29/2024 7:50 PM, kludge@panix.com wrote:
>>> =?UTF-8?Q?Arne_Vajh=C3=B8j?=  <arne@vajhoej.dk> wrote:
>>>> The code is VB6.
>>>>
>>>> But none of the problems are Basic specific. It is possible
>>>> to write the same bad code in C or Fortran or whatever.
>>>>
>>>> So it just shows that there are some really really bad programmers out
>>>> there.
>>>
>>> I have worked with people who could write spaghetti Fortran in any
>>> programming language available.  Did you know that LISP has a goto?
>>> It does.
>>>
>>>> PS: Good compilers may have detected the unreachable code. But it
>>>>      is still good vs bad compiler not good vs bad language.
>>>
>>> The exciting part is when they tell you not to remove the unreachable
>>> code,
>>> because the program crashes at runtime when you do that.
>>
>> Many moons ago I had to try to fix a number of programs that
>> crashed whenever run.  Back in those days a common method was
>> to add statements to display variables during execution.  I
>> had many cases where adding those statements made the program
>> work.
>>
>> bill
>
> Could it have been the variables were being incorrectly being optimised
> out, but adding a print statement would avoid that. I have seen that a
> few times
>

Usually it had to do with out of range access. Adding the displays
enlarged the I Area changing the location being accessed. Didn't
fix the program but made it run enough to troubleshoot once you knew
what the problem probably was.

bill

On 1/30/2024 2:06 AM, Dave Froble wrote:
> On 1/29/2024 8:02 PM, Arne Vajhøj wrote:
>> On 1/29/2024 7:50 PM, kludge@panix.com wrote:
>>> I have worked with people who could write spaghetti Fortran in any
>>> programming language available.
>>
>> "A real Fortran programmer can write Fortran in any language"
>>
>> Every time this comes up I post this Fortran/Pascal code:
>>
>>       PROGRAM GOTOFUN(INPUT,OUTPUT);

> I'm amused every time the GoTo bashing begins.
>
> Not only is there nothing wrong when using a branch operation, when
> appropriate, just look at the assembler listings after compilation.
> Branching is just about all assembler does, as required.
>
> Now, I won't defend what I and most consider improper use of the poor
> misunderstood GoTo statement.

The IT world 50-60 years ago had a GoTo problem.

The lack of structured constructs in assembler, Fortran 66,
original Dartmouth Basic etc. had resulted in a lot of
spaghetti code.

And as a result GoTo got a very bad reputation.

The IT world today does not have a GoTo problem.

Many languages does not support GoTo, but even in the languages
that do support GoTo it is typical not a common construct.

There are actual cases where GoTo (goto in case sensitive languages)
can result in more readable code than the structured approach.

In languages without exception support then a goto down to
cleanup code can be very readable.

In languages without labeled break then a goto out of an
inner loop can be very readable.

Arne

bill <bill.gunshannon@gmail.com> wrote:
>Many moons ago I had to try to fix a number of programs that
>crashed whenever run. Back in those days a common method was
>to add statements to display variables during execution. I
>had many cases where adding those statements made the program
>work.

Yes, this is a sign of a fandango on core. In Fortran it is
likely exceeding array bounds or bad parameter passing, but in
C the possibilities to screw up with pointers are endless.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."

On 1/30/2024 7:16 PM, Scott Dorsey wrote:
> bill <bill.gunshannon@gmail.com> wrote:
>> Many moons ago I had to try to fix a number of programs that
>> crashed whenever run. Back in those days a common method was
>> to add statements to display variables during execution. I
>> had many cases where adding those statements made the program
>> work.
>
> Yes, this is a sign of a fandango on core. In Fortran it is
> likely exceeding array bounds or bad parameter passing, but in
> C the possibilities to screw up with pointers are endless.

Bingo!!!

It was mostly Fortran but every once in a while some idiot
would do it in COBOL, too.

By the way, the Fortran was what you get when you have Electrical
and Mechanical engineers with too much time on their hands and you
decide to keep them busy by making them write business programs.

bill

On 1/30/2024 9:40 AM, Chris Townley wrote:
> On 30/01/2024 07:06, Dave Froble wrote:
>> On 1/29/2024 8:02 PM, Arne Vajhøj wrote:
>>> On 1/29/2024 7:50 PM, kludge@panix.com wrote:
>>>> =?UTF-8?Q?Arne_Vajh=C3=B8j?= <arne@vajhoej.dk> wrote:
>>>>> The code is VB6.
>>>>>
>>>>> But none of the problems are Basic specific. It is possible
>>>>> to write the same bad code in C or Fortran or whatever.
>>>>>
>>>>> So it just shows that there are some really really bad programmers out
>>>>> there.
>>>>
>>>> I have worked with people who could write spaghetti Fortran in any
>>>> programming language available.
>>>
>>> "A real Fortran programmer can write Fortran in any language"
>>>
>>> Every time this comes up I post this Fortran/Pascal code:
>>>
>>> PROGRAM GOTOFUN(INPUT,OUTPUT);
>>> LABEL L731,L113,L247,L588,L761,L922,L399,L601;
>>> VAR LBL:INTEGER;
>>> VAR I:INTEGER;
>>> BEGIN
>>> L731: GOTO L113;
>>> LBL:=399;
>>> L113: I:=0;
>>> WRITELN(I);
>>> L247: LBL:=601;
>>> IF(I<0)THEN GOTO L588 ELSE IF(I=0)THEN GOTO L922 ELSE GOTO L399;
>>> L588: I:=I+1;
>>> WRITELN(I);
>>> GOTO L399;
>>> L761: CASE(LBL)OF 399: GOTO L399; 601: GOTO L601; END;
>>> L922: I:=I+1;
>>> WRITELN(I);
>>> CASE(I)OF 1: GOTO L588; 2: GOTO L399; 3: GOTO L922; END;
>>> L399: GOTO L761;
>>> L601: END.
>>>
>>> :-)
>>>
>>> Arne
>>>
>>
>> I'm amused every time the GoTo bashing begins.
>>
>> Not only is there nothing wrong when using a branch operation, when
>> appropriate, just look at the assembler listings after compilation. Branching
>> is just about all assembler does, as required.
>>
>> Now, I won't defend what I and most consider improper use of the poor
>> misunderstood GoTo statement.
>>
>
> But unless used very carefully, it can create horrible spaghetti like code, and
> is also easy to screw up.
>
> Using proper structured constructs is much better - easier to read as well,
> hence better maintainability.
>
>

Prey tell, what structured construct will perform cleanup and exit? I always
expected a return from routines and such.

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On Tue, 30 Jan 2024 20:21:43 -0500, bill wrote:

> On 1/30/2024 7:16 PM, Scott Dorsey wrote:
>> bill <bill.gunshannon@gmail.com> wrote:
>>> Many moons ago I had to try to fix a number of programs that crashed
>>> whenever run. Back in those days a common method was to add
>>> statements to display variables during execution. I had many cases
>>> where adding those statements made the program work.
>>
>> Yes, this is a sign of a fandango on core. In Fortran it is likely
>> exceeding array bounds or bad parameter passing, but in C the
>> possibilities to screw up with pointers are endless.
>
> Bingo!!!
>
> It was mostly Fortran but every once in a while some idiot would do it
> in COBOL, too.

We had a machine that ran FORTRAN for the physics department. One guy had
a program that crashed the machine. As in, the microcode halted. That was
an array bounds error.

Full story:

http://www.bobeager.uk/anecdotes.html#hwhack

On 31/01/2024 04:28, Dave Froble wrote:
> On 1/30/2024 9:40 AM, Chris Townley wrote:
>> On 30/01/2024 07:06, Dave Froble wrote:
>>> On 1/29/2024 8:02 PM, Arne Vajhøj wrote:
>>>> On 1/29/2024 7:50 PM, kludge@panix.com wrote:
>>>>> =?UTF-8?Q?Arne_Vajh=C3=B8j?=  <arne@vajhoej.dk> wrote:
>>>>>> The code is VB6.
>>>>>>
>>>>>> But none of the problems are Basic specific. It is possible
>>>>>> to write the same bad code in C or Fortran or whatever.
>>>>>>
>>>>>> So it just shows that there are some really really bad programmers
>>>>>> out
>>>>>> there.
>>>>>
>>>>> I have worked with people who could write spaghetti Fortran in any
>>>>> programming language available.
>>>>
>>>> "A real Fortran programmer can write Fortran in any language"
>>>>
>>>> Every time this comes up I post this Fortran/Pascal code:
>>>>
>>>>       PROGRAM GOTOFUN(INPUT,OUTPUT);
>>>>       LABEL L731,L113,L247,L588,L761,L922,L399,L601;
>>>>       VAR LBL:INTEGER;
>>>>       VAR I:INTEGER;
>>>>       BEGIN
>>>> L731: GOTO L113;
>>>>       LBL:=399;
>>>> L113: I:=0;
>>>>       WRITELN(I);
>>>> L247: LBL:=601;
>>>>       IF(I<0)THEN GOTO L588 ELSE IF(I=0)THEN GOTO L922 ELSE GOTO L399;
>>>> L588: I:=I+1;
>>>>       WRITELN(I);
>>>>       GOTO L399;
>>>> L761: CASE(LBL)OF 399: GOTO L399; 601: GOTO L601; END;
>>>> L922: I:=I+1;
>>>>       WRITELN(I);
>>>>       CASE(I)OF 1: GOTO L588; 2: GOTO L399; 3: GOTO L922; END;
>>>> L399: GOTO L761;
>>>> L601: END.
>>>>
>>>> :-)
>>>>
>>>> Arne
>>>>
>>>
>>> I'm amused every time the GoTo bashing begins.
>>>
>>> Not only is there nothing wrong when using a branch operation, when
>>> appropriate, just look at the assembler listings after compilation.
>>> Branching
>>> is just about all assembler does, as required.
>>>
>>> Now, I won't defend what I and most consider improper use of the poor
>>> misunderstood GoTo statement.
>>>
>>
>> But unless used very carefully, it can create horrible spaghetti like
>> code, and
>> is also easy to screw up.
>>
>> Using proper structured constructs is much better - easier to read as
>> well,
>> hence better maintainability.
>>
>>
>
> Prey tell, what structured construct will perform cleanup and exit?  I
> always expected a return from routines and such.
>

It would depend on what is needing to be done

--
Chris

On Tue, 30 Jan 2024 23:28:53 -0500
Dave Froble <davef@tsoft-inc.com> wrote:

>
> Prey tell, what structured construct will perform cleanup and exit?
> I always expected a return from routines and such.
>

One option is named construct and named break.
Example below is from Go (golang) tutorial. Ada has something very
similar.

Loop:
for n := 0; n < len(src); n += size {
switch {
case src[n] < sizeOne:
if validateOnly {
break
}
size = 1
update(src[n])

case src[n] < sizeTwo:
if n+1 >= len(src) {
err = errShortInput
break Loop
}
if validateOnly {
break
}
size = 2
update(src[n] + src[n+1]<<shift)
}
}

Another option is defer clause.
From the same tutorial:

// Contents returns the file's contents as a string.
func Contents(filename string) (string, error) {
f, err := os.Open(filename)
if err != nil {
return "", err
}
defer f.Close() // f.Close will run when we're finished.

var result []byte
buf := make([]byte, 100)
for {
n, err := f.Read(buf[0:])
result = append(result, buf[0:n]...) // append is discussed
later. if err != nil {
if err == io.EOF {
break
}
return "", err // f will be closed if we return here.
}
}
return string(result), nil // f will be closed if we return here.
}

The third option, the one I like least (an understatement) is use of
exceptions. Despite my personal preferences, it's quite popular.

On 1/30/2024 11:28 PM, Dave Froble wrote:
> On 1/30/2024 9:40 AM, Chris Townley wrote:
>> On 30/01/2024 07:06, Dave Froble wrote:
>>> I'm amused every time the GoTo bashing begins.
>>>
>>> Not only is there nothing wrong when using a branch operation, when
>>> appropriate, just look at the assembler listings after compilation.
>>> Branching
>>> is just about all assembler does, as required.
>>>
>>> Now, I won't defend what I and most consider improper use of the poor
>>> misunderstood GoTo statement.
>>>
>>
>> But unless used very carefully, it can create horrible spaghetti like
>> code, and
>> is also easy to screw up.
>>
>> Using proper structured constructs is much better - easier to read as
>> well,
>> hence better maintainability.
>
> Prey tell, what structured construct will perform cleanup and exit?  I
> always expected a return from routines and such.

Let me try and show some examples.

In VB.NET.

Te first two examples could be done in VMS Basic (obviously
procedural not object oriented) but the last can not.

First with goto:

Imports System

Namespace GoToDemo
Public NotInheritable Class Luck
Private Shared rng As New Random()
Public Shared Function InLuck() As Boolean
Return rng.NextDouble() > 0.2
End Function
End Class
Public Class X
Private id As String
Private Sub New(id As String)
Me.id = id
Console.WriteLine("X {0} created", id)
End Sub
Public Shared Function Create(id As String) As X
If Luck.InLuck() Then
Return New X(id)
Else
Return Nothing
End If
End Function
Public Sub Close()
Console.WriteLine("X {0} closed", id)
End Sub
End Class
Public Class Program
Public Shared Sub Main(args As String())
Dim o1 As X = X.Create("A")
If o1 Is Nothing Then
Console.WriteLine("Error creating A")
GoTo lbl_done
End If
Dim o2 As X = X.Create("B")
If o2 Is Nothing Then
Console.WriteLine("Error creating B")
GoTo lbl_close1
End If
' 20 lines
Console.WriteLine("Part 1")
If Not Luck.InLuck() Then
Console.WriteLine("Error during execution")
GoTo lbl_close2
End If
' 20 lines
Console.WriteLine("Part 2")
lbl_close2:
o2.Close()
lbl_close1:
o1.Close()
lbl_done:
Console.ReadKey(True)
End Sub
End Class
End Namespace

It is with goto, but I don't think it is a bad use of goto. It just
jumps down to the cleanup code in case of an error.

Next traditional blocks:

Imports System

Namespace BlocksDemo
Public NotInheritable Class Luck
Private Shared rng As New Random()
Public Shared Function InLuck() As Boolean
Return rng.NextDouble() > 0.2
End Function
End Class
Public Class X
Private id As String
Private Sub New(id As String)
Me.id = id
Console.WriteLine("X {0} created", id)
End Sub
Public Shared Function Create(id As String) As X
If Luck.InLuck() Then
Return New X(id)
Else
Return Nothing
End If
End Function
Public Sub Close()
Console.WriteLine("X {0} closed", id)
End Sub
End Class
Public Class Program
Public Shared Sub Main(args As String())
Dim o1 As X = X.Create("A")
If o1 IsNot Nothing Then
Dim o2 As X = X.Create("B")
If o2 IsNot Nothing Then
' 20 lines
Console.WriteLine("Part 1")
If Luck.InLuck() Then
' 20 lines
Console.WriteLine("Part 2")
Else
Console.WriteLine("Error during execution")
End If
o2.Close()
Else
Console.WriteLine("Error creating B")
End If
o1.Close()
Else
Console.WriteLine("Error creating A")
End If
Console.ReadKey(True)
End Sub
End Class
End Namespace

No goto's. But I do not consider the code more readable than the
version with goto's. It sort of unnecessarily stretch out the
core logic.

And now the modern way with exceptions:

Imports System

Namespace ExceptionsDemo
Public NotInheritable Class Luck
Private Shared rng As New Random()
Public Shared Function InLuck() As Boolean
Return rng.NextDouble() > 0.2
End Function
End Class
Public Class XException
Inherits Exception
Public Sub New(msg As String)
MyBase.New(msg)
End Sub
End Class
Public Class X
Implements IDisposable
Private id As String
Public Sub New(id As String)
If Luck.InLuck() Then
Me.id = id
Console.WriteLine("X {0} created", id)
Else
Throw New XException("Error creating " & id)
End If
End Sub
Public Sub Dispose() Implements IDisposable.Dispose
Console.WriteLine("X {0} closed", id)
End Sub
End Class
Public Class Program
Public Shared Sub Main(args As String())
Try
Using o1 As New X("A")
Using o2 As New X("B")
' 20 lines
Console.WriteLine("Part 1")
If Not Luck.InLuck() Then
Throw New XException("Error during execution")
End If
' 20 lines
Console.WriteLine("Part 2")
End Using
End Using
Catch ex As XException
Console.WriteLine(ex.Message)
End Try
Console.ReadKey(True)
End Sub
End Class
End Namespace

Which I think is pretty nice. No goto's but still a compact
core logic.

For the not VB.NET knowledgable:

Using o1 As New X("A")
...
End Using

calls o1.Dispose() when the block is exited no matter how it
is exited - normal or exception does not matter Dispose is
always called.

Arne

On 2024-01-31 04:28:53 +0000, Dave Froble said:

> On 1/30/2024 9:40 AM, Chris Townley wrote:
>> On 30/01/2024 07:06, Dave Froble wrote:
>>> On 1/29/2024 8:02 PM, Arne Vajhøj wrote:
>>>> On 1/29/2024 7:50 PM, kludge@panix.com wrote:
>>>>> =?UTF-8?Q?Arne_Vajh=C3=B8j?= <arne@vajhoej.dk> wrote:
>>>>>> The code is VB6.
>>>>>>
>>>>>> But none of the problems are Basic specific. It is possible
>>>>>> to write the same bad code in C or Fortran or whatever.
>>>>>>
>>>>>> So it just shows that there are some really really bad programmers out
>>>>>> there.
>>>>>
>>>>> I have worked with people who could write spaghetti Fortran in any
>>>>> programming language available.
>>>>
>>>> "A real Fortran programmer can write Fortran in any language"
>>>>
>>>> Every time this comes up I post this Fortran/Pascal code:
>>>>
>>>> PROGRAM GOTOFUN(INPUT,OUTPUT);
>>>> LABEL L731,L113,L247,L588,L761,L922,L399,L601;
>>>> VAR LBL:INTEGER;
>>>> VAR I:INTEGER;
>>>> BEGIN
>>>> L731: GOTO L113;
>>>> LBL:=399;
>>>> L113: I:=0;
>>>> WRITELN(I);
>>>> L247: LBL:=601;
>>>> IF(I<0)THEN GOTO L588 ELSE IF(I=0)THEN GOTO L922 ELSE GOTO L399;
>>>> L588: I:=I+1;
>>>> WRITELN(I);
>>>> GOTO L399;
>>>> L761: CASE(LBL)OF 399: GOTO L399; 601: GOTO L601; END;
>>>> L922: I:=I+1;
>>>> WRITELN(I);
>>>> CASE(I)OF 1: GOTO L588; 2: GOTO L399; 3: GOTO L922; END;
>>>> L399: GOTO L761;
>>>> L601: END.
>>>>
>>>> :-)
>>>>
>>>> Arne
>>>>
>>>
>>> I'm amused every time the GoTo bashing begins.
>>>
>>> Not only is there nothing wrong when using a branch operation, when
>>> appropriate, just look at the assembler listings after compilation. Branching
>>> is just about all assembler does, as required.
>>>
>>> Now, I won't defend what I and most consider improper use of the poor
>>> misunderstood GoTo statement.
>>>
>>
>> But unless used very carefully, it can create horrible spaghetti like code, and
>> is also easy to screw up.
>>
>> Using proper structured constructs is much better - easier to read as well,
>> hence better maintainability.
>>
>
> Prey tell, what structured construct will perform cleanup and exit? I
> always expected a return from routines and such.

BASIC has its own variation on the classic TRY / THROW / CATCH /
FINALLY syntax:
WHEN ERROR IN
protected-statement [protected-statement,...]
USE
handler-statement [handler-statement,...]
END WHEN

But I'm mildly surprised it's lacking an ATEXIT or ilk. (I thought it
had that now, but I'm clearly mis-remembering.) I've used $dclexh and
ilk in various apps, or coded the app to release at rundown. (Not that
I prefer to have to implement manual cleanup, much as I'd like to avoid
explicitly deallocating memory in C. Garbage collection is so much
nicer, outside of kernel mode or other special app or context
requirements.)
Classic BASIC, Fortran, and C tend to be pretty bad at this
error-handling stuff (it's kinda been grafted on) without a fair amount
of work by the developer, and quite possibly with platform-specific
calls ($dclexh, etc) added. (Yes, I know about setjmp, atexit(), etc.
in C, and some other error-related syntax.) And yes, in BASIC, that
GOTO is one of the common ways to deal with errors, but I'd usually go
WHEN ERROR IN where I can. Or whatever other TRY / THROW / CATCH /
FINALLY / ATEXIT exists in the particular implementation.

And as for that earlier BASIC line number gibe, I'm sure most folks
working with BASIC on OpenVMS nowadays are using labels, as the labels
are just vastly more descriptive.

I've long thought this: "If the ERR function is used before an error
occurs or after an error is handled, the results are undefined" was
silly. UB? Seriously? Return some analog to SS$_NORMAL. Poof. No UB.

--
Pure Personal Opinion | HoffmanLabs LLC

Michael S <already5chosen@yahoo.com> wrote:
>
>The third option, the one I like least (an understatement) is use of
>exceptions. Despite my personal preferences, it's quite popular.

Exceptions can be very elegant or very inelegant... and it is entirely
possible to have an exception that doesn't clean anything up at all and
just exits and lets the operating system deal with the memory. On many
systems this is a great idea because being able to exit quickly on a failure
is more important than people give it credit for. On some other systems
that have memory management issues it can lead to leakage.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."

On 2024-01-31, Arne Vajhøj <arne@vajhoej.dk> wrote:
>
> For the not VB.NET knowledgable:
>
> Using o1 As New X("A")
> ...
> End Using
>
> calls o1.Dispose() when the block is exited no matter how it
> is exited - normal or exception does not matter Dispose is
> always called.
>

Unless there is a power failure or a system crash.

I wonder how many people think of that one when assuming that their
state reset code will _always_ run after execution of the routine
has started. :-)

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 1/31/2024 7:03 AM, Chris Townley wrote:
> On 31/01/2024 04:28, Dave Froble wrote:
>> On 1/30/2024 9:40 AM, Chris Townley wrote:
>>> On 30/01/2024 07:06, Dave Froble wrote:
>>>> On 1/29/2024 8:02 PM, Arne Vajhøj wrote:
>>>>> On 1/29/2024 7:50 PM, kludge@panix.com wrote:
>>>>>> =?UTF-8?Q?Arne_Vajh=C3=B8j?= <arne@vajhoej.dk> wrote:
>>>>>>> The code is VB6.
>>>>>>>
>>>>>>> But none of the problems are Basic specific. It is possible
>>>>>>> to write the same bad code in C or Fortran or whatever.
>>>>>>>
>>>>>>> So it just shows that there are some really really bad programmers out
>>>>>>> there.
>>>>>>
>>>>>> I have worked with people who could write spaghetti Fortran in any
>>>>>> programming language available.
>>>>>
>>>>> "A real Fortran programmer can write Fortran in any language"
>>>>>
>>>>> Every time this comes up I post this Fortran/Pascal code:
>>>>>
>>>>> PROGRAM GOTOFUN(INPUT,OUTPUT);
>>>>> LABEL L731,L113,L247,L588,L761,L922,L399,L601;
>>>>> VAR LBL:INTEGER;
>>>>> VAR I:INTEGER;
>>>>> BEGIN
>>>>> L731: GOTO L113;
>>>>> LBL:=399;
>>>>> L113: I:=0;
>>>>> WRITELN(I);
>>>>> L247: LBL:=601;
>>>>> IF(I<0)THEN GOTO L588 ELSE IF(I=0)THEN GOTO L922 ELSE GOTO L399;
>>>>> L588: I:=I+1;
>>>>> WRITELN(I);
>>>>> GOTO L399;
>>>>> L761: CASE(LBL)OF 399: GOTO L399; 601: GOTO L601; END;
>>>>> L922: I:=I+1;
>>>>> WRITELN(I);
>>>>> CASE(I)OF 1: GOTO L588; 2: GOTO L399; 3: GOTO L922; END;
>>>>> L399: GOTO L761;
>>>>> L601: END.
>>>>>
>>>>> :-)
>>>>>
>>>>> Arne
>>>>>
>>>>
>>>> I'm amused every time the GoTo bashing begins.
>>>>
>>>> Not only is there nothing wrong when using a branch operation, when
>>>> appropriate, just look at the assembler listings after compilation. Branching
>>>> is just about all assembler does, as required.
>>>>
>>>> Now, I won't defend what I and most consider improper use of the poor
>>>> misunderstood GoTo statement.
>>>>
>>>
>>> But unless used very carefully, it can create horrible spaghetti like code, and
>>> is also easy to screw up.
>>>
>>> Using proper structured constructs is much better - easier to read as well,
>>> hence better maintainability.
>>>
>>>
>>
>> Prey tell, what structured construct will perform cleanup and exit? I always
>> expected a return from routines and such.
>>
>
> It would depend on what is needing to be done
>

Final cleanup, if required, and exit the program.

Knew a guy that would us a gosub to go to the END statement. Drove me nuts.

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On 1/31/2024 11:17 AM, Scott Dorsey wrote:
> Michael S <already5chosen@yahoo.com> wrote:
>>
>> The third option, the one I like least (an understatement) is use of
>> exceptions. Despite my personal preferences, it's quite popular.
>
> Exceptions can be very elegant or very inelegant... and it is entirely
> possible to have an exception that doesn't clean anything up at all and
> just exits and lets the operating system deal with the memory. On many
> systems this is a great idea because being able to exit quickly on a failure
> is more important than people give it credit for. On some other systems
> that have memory management issues it can lead to leakage.

It is probably a bit easier to implement exceptions in languages
with garbage collection and a lot easier for developers to avoid
memory leak bugs.

$ type mem.cpp
#include <iostream>
#include <string>

using namespace std;

class X
{ private:
string id;
public:
X(string id) { this->id = id; cout << "Allocate " << id << endl; }
virtual ~X() { cout << "Deallocate " << id << endl; }
};

void f2()
{ throw "Houston we have a problem";
}

void f1()
{ X o2("o2");
X *o3 = new X("o3");
f2();
delete o3;
}

int main()
{ try
{
X o1("o1");
f1();
}
catch(char *ex)
{
cout << ex << endl;
}
return 0;
}

$ cxx mem.cpp
$ cxxlink mem
link mem
$ run mem
Allocate o1
Allocate o2
Allocate o3
Deallocate o2
Deallocate o1
Houston we have a problem
$

We see that o2 did get deallocated, but o3 did not get deallocated.

Arne

On 1/31/2024 1:22 PM, Simon Clubley wrote:
> On 2024-01-31, Arne Vajhøj <arne@vajhoej.dk> wrote:
>> For the not VB.NET knowledgable:
>>
>> Using o1 As New X("A")
>> ...
>> End Using
>>
>> calls o1.Dispose() when the block is exited no matter how it
>> is exited - normal or exception does not matter Dispose is
>> always called.
>
> Unless there is a power failure or a system crash.

I guess that is also a form of exit.

:-)

> I wonder how many people think of that one when assuming that their
> state reset code will _always_ run after execution of the routine
> has started. :-)

Probably none. But it probably does not matter either.

The construct is used to free unmanaged resources in the
process. Open files, open network connections like database
connections, unmanaged memory etc.. All stuff that goes
away if the process is gone.

I have never seen the construct used to reset an out
of process state (persisted state). And I have seen
a lot of C#, VB.NET, Java, Python etc. code using the
construct.

If there is a need for a consistent out of process
state (persisted state), then it has to be transactions.

Arne

In article <upe3ib$1kker$1@dont-email.me>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
>On 1/31/2024 11:17 AM, Scott Dorsey wrote:
>> Michael S <already5chosen@yahoo.com> wrote:
>>>
>>> The third option, the one I like least (an understatement) is use of
>>> exceptions. Despite my personal preferences, it's quite popular.
>>
>> Exceptions can be very elegant or very inelegant... and it is entirely
>> possible to have an exception that doesn't clean anything up at all and
>> just exits and lets the operating system deal with the memory. On many
>> systems this is a great idea because being able to exit quickly on a failure
>> is more important than people give it credit for. On some other systems
>> that have memory management issues it can lead to leakage.
>
>It is probably a bit easier to implement exceptions in languages
>with garbage collection and a lot easier for developers to avoid
>memory leak bugs.
>
>$ type mem.cpp
>#include <iostream>
>#include <string>
>
>using namespace std;
>
>class X
>{
>private:
> string id;
>public:
> X(string id) { this->id = id; cout << "Allocate " << id << endl; }
> virtual ~X() { cout << "Deallocate " << id << endl; }
>};
>
>void f2()
>{
> throw "Houston we have a problem";
>}
>
>void f1()
>{
> X o2("o2");
> X *o3 = new X("o3");
> f2();
> delete o3;
>}
>
>int main()
>{
> try
> {
> X o1("o1");
> f1();
> }
> catch(char *ex)
> {
> cout << ex << endl;
> }
> return 0;
>}
>
>$ cxx mem.cpp
>$ cxxlink mem
>link mem
>$ run mem
>Allocate o1
>Allocate o2
>Allocate o3
>Deallocate o2
>Deallocate o1
>Houston we have a problem
>$
>
>We see that o2 did get deallocated, but o3 did not get deallocated.

This is well-known in older C++ code; since C++11 one should be
using `std::unique_ptr<T>` to avoid this sort of issue. Code
using an older dialect could look at something like the
venerable ScopeGuard as a defensive technique to guard against
leaks.
https://www.drdobbs.com/article/print?articleId=184403758&siteSectionName=cpp

- Dan C.