LabVIEW Style Challenge - Error Wires

[paul_a_cardinale]

Oops.  One of the VIs in there (Clear_Errors_Small_Icon.vi) was password protected.

The attached version has the PW removed.

[Taggart]

---

@SteenSchmidt wrote:

The two clear error functions are here to explicitly show that the close will be done regardless of error input, and will never output an error.

---

Why shouldn't Close output an error? What if the closing failed? Templating can lead to these kinds of oversights.

🙂

---

As to close outputting an error, ok great, but what do I do with that? Try to close the file again? A cleanup function that outputs an error just adds noise. It's generally not actionable.

[Taggart]

---

@SteenSchmidt wrote:

---

@PragmaTest wrote: I accept that, even in my daily work : I don't discuss each small detail, I am open to keep and use code that I would have not done like it is. I focus on big issues, I respect freedom of each developer. I'm quite sure that a company where each developer have no freedom and is targeted for doing something different than his colleagues falls in high turnover.

Of course the big issues are more important than the small details. But the big issues are easy, the small details are what can actually move the status quo the most over time. All those small steps to improve will actually matter 1000x a year down the line, when your big applications are maintainable and extendable because they are lean and are outputting the proper errors.

I'll take well designed and reasoned code that is maybe a little sloppy (it does still have to be readable even if it takes a little extra effort) over poorly designed code with perfectly straight wires every day.

[SteenSchmidt]

---

@Taggart wrote:

---

@SteenSchmidt wrote:

The two clear error functions are here to explicitly show that the close will be done regardless of error input, and will never output an error.

---

Why shouldn't Close output an error? What if the closing failed? Templating can lead to these kinds of oversights.

🙂

---

As to close outputting an error, ok great, but what do I do with that?

---

As with all other errors, you either:

1) Fix it yourself and don't tell anybody.

2) Output the error and let your caller decide what to do. You do not know who your caller is and therefore know nothing about their requirements or their capabilities to fix stuff.

In this particular case there could be different errors out of Close, what you do with them would depend on the specific error:

- Refnum was invalid. You probably should tell your caller that they invalidated your refnum while you used it.

- Refnum was already closed. Perhaps your job is already done and everybody is happy, but that depends on what happened upstream: If you received a valid refnum perhaps now is the time to tell your caller that you experienced a runtime error so they know their software has problems. It's not great to have refnums close themselves at random times.

- It could be an upstream error, so close performed fine but something before that may need your attention, some of that fixable by you other things need to be told to your caller.

What if MS Word couldn't save your file and just silently closed anyways without telling you as its human operator? Or if MS Word was called headless by ActiveX and couldn't save a file, but closed silently without telling its caller that it failed? MS Word shouldn't mindlessly attempt to save again and again (it could do a retry, depending on why it couldn't save the file the first time), but its crucial that you tell your caller about your failures.

Stacking silently failing software components on top of each other leads to unstable and untrustworthy software that will constantly surprise you. Yes, it takes a lot of work to do all of this, but in the end you will have predictable and useful software.

UIs and error handling are probably the two most resource demanding activities with software. UIs because humans are difficult. Error handling because the sunshine scenario is just one path between a hundred kinds of failures. That's why I don't agree with "The important stuff is the architecture, never mind the small details". No, architecture is easy. Getting all the details right is hard. My mission is to make those details easy to do, so they will get done. I have made tools to create error translation VIs and to apply error strategy information automatically to VI descriptions for instance, because those two things are hard labor to do, but really important to users of your software.

[PragmaTest]

@SteenSchmidt

Regarding a word report, I would wire error flow of the save as function normally (or at least the error output), but would never wire error in and error out for the close function.

I hope the cleanup topic will be talked at GdevCon Glasgow, it's cool to see other points of view 🙂

[SteenSchmidt]

---

@Taggart wrote:

---

I'll take well designed and reasoned code that is maybe a little sloppy (it does still have to be readable even if it takes a little extra effort) over poorly designed code with perfectly straight wires every day.

---

Of course. But error handling is not style, it is functionality. It can deterministically be correct or not correct.

Straight wires or excessive white space is in the same category as indenting function blocks in text based languages or choosing meaningful names for stuff. It increases perceived complexity without adding functional value. If it was all perfected automatically you'd take it, right? So it's not so much a question of creative freedom, as it is a lack of easy ways to get there. If you need to labor with it, you'll skip the stuff that you don't have time or patience to do. I agree. I wish for a well oiled diagram cleanup, until then I'm not bashing anybody for not having 8px between objects on their diagrams.

[SteenSchmidt]

---

@PragmaTest wrote:

@SteenSchmidt

Regarding a word report, I would wire error flow of the save as function normally, but would not wire error in and error out for the close function.

---

In the case of Close Config save is part of the close, but ok, let's focus on close only;

If it doesn't matter if it got closed or not, why do it in the first place? Remove the close then. If your counter argument is "If close failed because the refnum was already closed, THEN it doesn't matter". Well, now you're already looking at the different errors coming out of close, and deciding which error cases to treat in which way. Exactly as I say.

[PragmaTest]

About the close config file which can save the config file, I would probably wire the error output in case of a write, but not in case of a read.

[SteenSchmidt]

---

@PragmaTest wrote:

About the close config file which can save the config file, I would probably wire the error output in case of a write, but not in case of a read.

---

I would inspect the error out and take different actions depending on the specific error. If the error was that the refnum couldn’t be closed, that’s serious business: Now you at least have a memory leak, and you potentially have a locked file nobody (including the OS) can do anything with.

I’m worried when people take so lightly on errors 😞 They are there for a reason, and as several here have mentioned: You in practice can’t consider Close Config’s source code, so you don’t know which errors can come out of it. You as minimum need to have a look.

[Taggart]

---

@SteenSchmidt wrote:

---

@Taggart wrote:

---

I'll take well designed and reasoned code that is maybe a little sloppy (it does still have to be readable even if it takes a little extra effort) over poorly designed code with perfectly straight wires every day.

---

Of course. But error handling is not style, it is functionality. It can deterministically be correct or not correct.

Straight wires or excessive white space is in the same category as indenting function blocks in text based languages or choosing meaningful names for stuff. It increases perceived complexity without adding functional value. If it was all perfected automatically you'd take it, right? So it's not so much a question of creative freedom, as it is a lack of easy ways to get there. If you need to labor with it, you'll skip the stuff that you don't have time or patience to do. I agree. I wish for a well oiled diagram cleanup, until then I'm not bashing anybody for not having 8px between objects on their diagrams.

---

---

I agree. error handling is not style. It is very much design. It's the obsession over things like straight wires, whitespace, number of wire bends or crossings, etc that I think is misguided. We desperately need an autoformatter so that we don't need to worry about minutae that don't functionally matter at all.