Revise syntax for try statement

[stirlingstout]

Currently we have

Since the whole point of catch is that is handling exceptional (but foreseeable) situations it should stand out, and with the indentation the same as the code inside the try it doesn't. It also makes it appear that the catch is concerned with the statement immediately before it which it doesn't (mind you, I would always teach that (almost) the only way to guarantee that there is just one statement in the try block that could go wrong is only to have one statement in the block, when the catch would apply to the immediately preceding statement!)

I don't think this is ideal, and it is inconsistent with most (if not all) other languages (not that consistency is Elan's point).

[richardpawson]

Unfortunately the whole way that the frame editor works does not permit anything in a multi-line statement to be at the same level of indentation as the delimeters (i.e. the try and end try in this case) - and I think that is what you are asking for.

I understand your concern - we faced the same dilemma, if you recall, with an if-statement, which - if the else option was used - originally looked like this:

if a > b
  print "pass"
  else
    print "fail"
end if

This was also unsatisfactory, because the code within the else clause is more indented than the (implicit) then clause. And the following was not an option (as describe above):

if a > b
  print "pass"
else
  print "fail"
end if

After much debate we decided on:

if a > b
  then
    print "pass"
  else
    print "fail"
end if

Which is a bit verbose, but is more consistent, and at least then is a widely recognised term and the whole construct verbalises well. I recall you were happy with this decision.

We could do something similar for try catch, but then we would have to add an additional line and keyword, for example:

try
  this
    call something()
  catch e
    print "An error message
end try

But what should the keyword (this above) be? Possibly doing ,running, executing?

And is the cure an improvement on the ailment?

Another possibility might be to put the catch clause at the top, bounded by a new end catch:

try
  catch e
    print "An error message
  end catch
  call something()
end try

(not sure I like that one - just trying to explore possibilities)

[stirlingstout]

I did wonder if it was the same problem. Yes, that's exactly what I was 'wanting'.

Is the frame editor 'problem definitely insurmountable? There's no way to finesse it by something like 'gluing' two frames together (try and catch delimiting the first, then catch and end try for the second? I prefer the word finesse rather than kludge for obvious reasons!

If not then what about

try

• to*
• open a file catching in e # or just catch* for familiarity
• anything that goes wrong end try*

try

• doing*
• these things*
• catching in e*
• anything that goes wrong end try*

which, I think, fits nicely with the verbalisation principle. I quite like the idea of capturing in

Is a finally clause in the pipeline?

John

On Tue, 5 Nov 2024, 13:22 Richard Pawson, @.***> wrote:

Unfortunately the whole way that the frame editor works does not permit anything in a multi-line statement to be at the same level of indentation as the delimeters (i.e. the try and end try in this case) - and I think that is what you are asking for.

I understand your concern - we faced the same dilemma, if you recall, with an if-statement, which - if the else option was used - originally looked like this:

if a > b print "pass" else print "fail" end if

This was also unsatisfactory, because the code within the else clause is more indented than the (implicit) then clause. After much debate we switched it to:

if a > b then print "pass" else print "fail" end if

Which is a bit verbose, but is more consistent, and I recall you were happy with this decision.

We could do something similar for try catch, but then we would have to add an additional line and keyword, for example:

try this call something() catch e print "An error message end try

But what should the keyword (this above) be? And is the cure an improvement on the ailment? (At least with the if statement, then was both widely recognisable, and verbalised well.)

— Reply to this email directly, view it on GitHub https://github.com/elan-language/LanguageAndIDE/issues/824#issuecomment-2457171656, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAQQABYK6BMOIPZ52TQEQM3Z7DA73AVCNFSM6AAAAABRGLJ7MKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINJXGE3TCNRVGY . You are receiving this because you authored the thread.Message ID: @.***>

John

[richardpawson]

Is the frame editor 'problem definitely insurmountable?

Changing the editor is not impossible but

• It would be a huge effort (months!) to change the fundamentals of the frame based editor it at this stage
• I don't think the constraint is wrong anyway!

I will add a ticket to revise trystatement. I think I prefer doing to to (the latter works fine if the only thing that follows it is e.g. call xxx but it verbalises less well if it is multiple statements, or even if it is a single assignment statement, which it can be).

I'm not sure 'in adds a lot of clarity or improved verbalisation. Adding the word exception might help e.g. catch exception in e. What do you think?

No plans for finally:

• Not likely to be known/used by many teachers now
• I'm not keen on it as a programming construct!
• Given that Elan functions (and procedures) exit always from the final statement anyway, you can put anything you always need to happen in the return or immediately above it.

[stirlingstout]

I just thought if we were having doing then it should be catching.

I like catch(ing) exception in e: there's no penalty to the user since it's part of the template, and it does say exactly what happens.

Not bothered about finally, but can I throw an exception up the call stack?

[richardpawson]

can I throw an exception up the call stack?

Don't think I've ever tried it in Elan myself - can I suggest you try it out and report any findings?

[richardpawson]

Final implemented syntax for try statement is e.g.:

  try
    doing
      call foo()
      print "not caught"
    catching exception in e
      var s set to ""
      set s to e
      print s
  end try

Because this involved the creation of the exception keyword, I also took the opportunity to improve the verbalisation of the `throw' statement, which is now e.g.

throw exception "Error message"