Conditional For Loops as 'Trial and Error' resolver

[Ton Plomp]

Recently I realized that I'm starting to use the conditional for loop more and more as an 'Error' catcher.

I try to come up with the number of possible resolvers for an error situation, and run these in a for-loop, as soon as any of these resolvers, resolved the issue, I exit the for loop.

One example is found in LVDIFF2, where Mercurial outputs mixed paths (using / and \ as path separators), in for different states I try to fix this path:

1. Use a standard string to path function
   
2. Use a function to read a linux path (only / separators)
   
3. Use a function to replace / with \ (works on Windows)
   
4. Use a function to replace \ with / (works on Linux/Mac)
   

After each iteration I check to see if the created path actually exists, and exit the loop if the path is found.

If the path is not found at all the code will fail, but at least we tried the best we could.

Here's a snippet (with screenshots) of that section:

Is anybody else using the conditional for loop in such a way?

Other alternatives could be using an array and auto-indexing to limit the number of iterations of the for loop.

Ton

[ShaunR]

I'm not a fan of the "brute force and ignorance" method of resolving stuff. I think it is an anti-pattern.

If you know what the options are, then there is nearly always a way of detecting and using the correct method/case without incurring the potentially long pauses whilst the VI "searches" for the correct solution. I do. however, use it for exiting a VI early if, for example, I'm doing a linear search and find the answer.

In your example, wouldn't the "Scan String For Tokens" allow you to find which path separator is being used and choose accordingly?

Try Multiple Type-casts.

[Aristos Queue]

Ton: By complete coincidence, a fairly old 2010 thread got new life yesterday when someone posted on it, and it is a post from Norm showing exactly what you show here.

[Yair]

Ton: By complete coincidence, a fairly old 2010 thread got new life yesterday when someone posted on it...

It's not coincidence. Look one post above yours.

[MikaelH]

I'll do it as well, you're not alone.

One example is when initializing communication with instruments that can be configured for different baud rates.

[asbo]

I think it's an interesting accessory to the bag of tricks, but like ShaunR don't tend to have situations where there are several generic possibilities to solve an error. Either I'll know the details of the proceeding functionality and can specifically handle the outcome, or I don't know enough and consider it a cancel/abort/stop action.

That's not to say it doesn't have utility in discovery-esque scenarios, like Mikael describes. In fact, I think it's the only sane, scalable way to tackle such a problem. I don't often find myself in the situation that Norm describes in the original thread with several difference references types, but I think it's an acceptable solution in situations where you're trying to maximize reuse and minimize redundancy.

[Jeffrey Habets]

Yup!

Perfectly legit way of working if you ask me.. You need to write the code anyway, so why not use it to do the 'checking'. It saves you the work of writing the extra code to check what the exact format of the path is.

As Mike, I most often use this construct too when attempting to connect to certain instruments.

[Aristos Queue]

That's not to say it doesn't have utility in discovery-esque scenarios, like Mikael describes. In fact, I think it's the only sane, scalable way to tackle such a problem.

In at least some instances, I would hope that you would reach for a parallel solution to run all of these tests in parallel, such as kicking off a Parallel For Loop or launching N Asynchronous Call By Reference operations and taking the first one that returns TRUE (and aborting the others).

[asbo]

In at least some instances, I would hope that you would reach for a parallel solution to run all of these tests in parallel, such as kicking off a Parallel For Loop or launching N Asynchronous Call By Reference operations and taking the first one that returns TRUE (and aborting the others).

You make an excellent point. My inclination would probably be a product of the duration of these tests - if we're talking on the scale of single-second operations, a parallel pattern probably isn't going to pay out (to development and debug time) unless you have a non-trivial number of tests which can all equally be run independently. My mind still draws to the hardware example MikaelH gave, have you used this pattern before on a software-only routine or is it just thought-play?

[ShaunR]

Ton. For your path example, I would have gone for something like this. Has one other advantage over the BFI method in that paths like "c:\temp\//test//text.txt" where you have multiple separators back-to-back, are also catered for. Slightly more complicated than it needed to be really, due to the regex escape char being the same as the windows path char. I'm sure this can be improved upon though.