Try-Catch Finally improvement

[andrzej.kniola (Andrzej Knioła)]

@Cosmin_Ion_Nicolae

When the exception is not caught in the try catch that means that the current try catch block should not handle the exception so execution needs to be paused and the error need to be thrown to a higher level. So finally should not be executed. Similarly when an error is Re-thrown.

(emphasis mine)

I completely disagree. The whole purpose of the Finally block is that it’s always executed.
If something should not be always executed, it should not be in a Finally block (or at least it should be conditioned in an If etc. That’s why you see things like if (conn != null) conn.Close/conn.Dispose; [depending on reuse needs]) in the Finally blocks when using is not used.

Consider having a db connection - whatever happens, you always want to make sure connection is closed.
Or a file handle is released, if working on files. Or a socket is closed etc.

One of the base constructions in .Net when working with outside resources is the using clause. It’s whole purpose is to make it easier to make sure that external resources are disposed, which was previously done with try-finally.

Everywhere you look in the MSDN documentations (at least everywhere I was able to find it), there are always sentences like:

Some resource cleanup, such as closing a file, needs to be done even if an exception is thrown. To do this, you can use a finally block. A finally block always executes, regardless of whether an exception is thrown.

Now if we change this predicament, these are some scenarios that you could run into:

• You read a file as a readwrite stream. You mess something up during this and an exception is thrown (one that is not catched). You have stream closing in Finally (since there’s no using in WF). Stream is never closed, file is now locked. That was the daily transaction file. Before you figure out which robot didn’t release it, SLA’s are in danger.
• You introduce new operations to an existing db connection. There’s a rare bug that was not diagnosed yet. 10 robots are using this functionality constantly and have long-running jobs. You have conn.close in Finally. You run into a connection limit and all robots fail. Your DBA wants to do nasty things to you.
• Simpler example - you’re processing PDF’s in a way that they need to be opened (let’s say relative scraping). You open up a PDF, try to do scraping. An unexpected PDF is thrown into the mix (badly formatted, maybe even corrupted). You have KillProcess (because CloseWindow isn’t safe enough) in your Finally clause. That never executes. You have a lingering Acrobat window that messes up reading next PDF’s (wrong window is found etc.).

All of the above can be handled currently in a different way. But all of them would be much easier with a Finally block that executes always.

@Cosmin_Ion_Nicolae

For instance if you have an uncaught exception by definition you don’t know exactly what happened so you don’t know at that level how to treat it and the finally will still get executed.

Yes, and that’s the point. If a lower level workflow does not know how to handle an error in it’s execution, or provide enough information/stabilise so a higher level one could handle it, how a higher level one should know what to do? With proper separation, it shouldn’t even know what the lower level one is doing (only the input/output, rest is an implementation detail).

It’s similar as with Catch reordering - we write in (VB).Net, expecting it to behave like one. But situation that would be a compiler error (unreachable catch) is the way to go. Thing is, noone will figure it out without basically tripping over it, because it’s different to what we were “programmed” to look out for.

With the Catch reordering it’s actually a pretty good change, because it lessens the burden of design. With Finally, it’s the opposite.

This went a little longer, but IMHO, current Finally (I know, it’s MS implementation, w/e) in the Try-Catch-Finally activity does not serve it’s purpose. At all.
It’s basically just another Sequence tacked on at the end.
And this is the core problem - it brings a promise, or an expectation, of working like a tcf block, but doesn’t. Anyone who used any language that has a finally concept will get biten by this unless they by chance find out earlier that it doesn’t work (I was going to say “as expected”, but since it’s the core function of Finally to always execute, let’s call it as it is - it’s not fit for purpose = it doesn’t work).

I think @richarddenton put it exactly right:

@richarddenton

Sort of defeats the purpose of a finally right?

I would highly urge you to reconsider or, if you don’t want to reimplement tcf which I can understand, publicize it! Very few people actually know about how this sudo-tcf really works and that’s a huge risk.