Try..except..finally..end; ??

[David Heffernan 2514]

with in Python is a great piece of syntax. Really, that language is so well designed and thought out.

[corneliusdavid 292]

On 10/27/2025 at 6:40 AM, Anders Melander said:

Concise, maybe. Clarity, no.

Personal opinion: I think @pyscripter's suggestion is far clearer than

 

try

  try

  except

  end

finally

end

 

When filled with code and logic branches, etc. this multi-level indentation gets messy, plus two extra lines for the extra try/end in the middle.

[corneliusdavid 292]

On 10/27/2025 at 3:16 PM, David Heffernan said:

I want to know why people are so keen to handle exceptions. Why are we wanting to do that. The whole point of exceptions is that we don't need to deal with errors at a place where we don't know how to deal with them.

I find this to be a surprising and very strange statement. As programmers trying to provide a nice, smooth experience for end users, our job is to handle a wide variety of situations that we may or may not foresee. When writing to a file, for example, you should check to see if it exists and if not, create it, then start writing. But what if it's locked or read-only, or has a permission error, or has some other corruption, or a network error? Are you supposed to check for every possible problem proactively so that you don't have to use a try/except as a general catch-all? It's far better to write an exception handler that gracefully logs the error and puts up a message to the user rather than letting the system generate an ugly default error message. If you detect an exception is getting generated often, figure out how to prevent it so it's not raised; but the idea to just let it go because you don't know what to do baffles me. Many times, library calls or third-party components will raise exceptions for unknown or unhandled issues; if we don't handle them, it's just unprofessional.

 

Another example: We have a parsing function in our library that expects strings to be in a certain format--and 99% of the time they are. To save programming time, we assume it is in the right format and just parse it. But that routine is in a try/except and if for some rare reason the string is not able to be parsed, the except clause displays the invalid string. Then we can correct the source of the problem rather than have 40 different if/else clauses or a complex regular expression to catch every possible nuance. Using try/except in this case saves a lot of programmer time.

 

One more thing: Exceptions are NOT always errors. But--you should know this!  Am I missing something in your statement?

[Anders Melander 2203]

21 minutes ago, corneliusdavid said:

plus two extra lines for the extra try/end in the middle.

Who cares about that?

 

I frequently put vertical white space, at least one line, after begin, try, etc. and before end, finally, except, etc. to improve the readability of complex code.

[corneliusdavid 292]

2 minutes ago, Anders Melander said:

Who cares about that?

I do. But each to their own style. To me, the extra verbosity makes it more cluttered. I much prefer the curly braces of C-like languages because the words "begin" and "end" just get muddied in with all the identifiers and "real" code. But I'm stuck in Pascal and so use "hanging ends" on if statements and so forth to save an extra line. I try to use as little vertical space as possible.

 

And blank lines after begin and before end, etc.?  I personally feel that's wasteful  because to me, the indentation is enough to identify a block of code; I reserve blank lines for separating groups of contextually related code.

 

Like I say though, each to their own.

[Anders Melander 2203]

3 minutes ago, corneliusdavid said:

if we don't handle them, it's just unprofessional.

In my applications, unhandled exceptions are allowed to propagate all the way to the top to be caught by madExcept, and presented to the user as a bug report - Because that's what they are: Bugs, and I want them treated as such so the problem can be fixed.

 

10 minutes ago, corneliusdavid said:

It's far better to write an exception handler that gracefully logs the error and puts up a message to the user rather than letting the system generate an ugly default error message.

I would catch a category of errors (permission denied, sharing violation, etc) and let the rest propagate.

For example, I have a function that replaces one file with another. It deals with all the different errors that can happen, temporary sharing violations, virus scanners getting in the way, network glitches, atomicity (either move the file, replacing a possible duplicate at the target and removing the source or do nothing), backup files, retries, etc. etc. And that's 500 lines of code to move a file without bothering the user with the details unless absolutely necessary: For example an I/O error or an invalid filename. Those are soft errors. The stuff that I either didn't anticipate or which must not happen I let propagate.

[Anders Melander 2203]

15 minutes ago, corneliusdavid said:

Like I say though, each to their own.

Sure, but if you don't like the language regardless then it's like going into an Italian restaurant and complaining that they don't serve Bouillabaisse 🙂 

[corneliusdavid 292]

3 minutes ago, Anders Melander said:

The stuff that I either didn't anticipate or which must not happen I let propagate.

Yes, I agree with this when you've done all you can reasonably do to catch/handle/prevent problems and there's a top-level exception-catcher to report/log bugs. But to not use any try/except strikes me as a very bad rule.

[Anders Melander 2203]

1 minute ago, corneliusdavid said:

But to not use any try/except strikes me as a very bad rule.

I think he meant not to handle exceptions at a level where you don't know what to do with them.

[Attila Kovacs 695]

28 minutes ago, Anders Melander said:

I think he meant not to handle exceptions at a level where you don't know what to do with them.

yup.

I always think in terms of: try A, except plan B; end.
If I don’t have a plan B, then it’s not the right place to handle it.

[Tommi Prami 161]

On 10/27/2025 at 5:48 PM, pyscripter said:

try

except

finally

end

 

try

finally

except

end

 

If implemented this would be must, to put the order that would fill need in hand.

Mainly for me this would remove on indentation and the one thing I can't remember what is called, like begin .. end... "collection of code lines"

Edited October 31 by Tommi Prami
Finished the sentence

[Lars Fosdal 1987]

Personally, I'd prefer to keep the two existing constructs that needs nesting, over introducing yet another two constructs in addition.