Day 038 - Errors, exceptions and indirection

Picking up the tutorial after the summer publishing break, I'm at page 375, Automatic Management of Errors. Ah, if only that were really true. I don't mean WinDev specifically, I mean it would be so nice if all errors could be handled automagically. But let's see what WinDev has in store. 

Error and exception handling

No doubt there are many different schemes out there for handling errors. I'm aware of two main approaches: error handling and exception handling. 

For most of us, errors are more familiar than exceptions. Let's say you call a function, and that function returns an error code. You're either going to check for the error or ignore the error. If you check for it (advisable) then you have to make a decision at that point what's going to happen to program execution. Will you terminate? Will you show a message to the user? Whatever you do, your code is responding when that error happens. 

If you've worked in .NET or Java, you're probably familiar with exceptions as well. Exceptions allow you to separate the error handling from the point at which the error occurs. 

For instance, let's say you have three function calls that you have to call in sequence, and any one of them can introduce an error. A return value of > 0 indicates success. Your code might look like this:

IF ProcedureA() THEN
	IF ProcedureB() THEN
		IF ProcedureC() THEN
			// Success!
		ELSE
			// Procedure C failed
		END
	ELSE
		// Procedure B failed
	END
ELSE
	// ProcedureA failed	
END

You need the nested IF statements to ensure that you stop execution on an error. It works, but it's a bit clunky. 

Here's another way to write that code using exceptions:

WHEN EXCEPTION IN
	ProcedureA()
	ProcedureB()
	ProcedureC()
DO
	// Handle the exception	
END

Full disclosure: I haven't played with any of this code yet; I'm just observing that it's legal code, and that WinDev does have support for exceptions. I have used exceptions a lot in Java and .NET, and they are often a much more elegant way to handle errors in complex code. 

Check out the WinDev reference page on exception handling for more

Once again this has been a bit of a diversion from the tutorial, which in this section focuses on automatic error handling. 

At the top of the code editor window you will see two links:

Both links bring up the same window, but the first displays the error handling tab:

while the second displays the exception handling tab:

Based on these two windows you might assume that exceptions are for fatal errors and errors are for non-fatal errors. That seems to be the convention in WinDev, and again I don't have the WinDev experience to back up my assertions, but it seems to me that you can choose in your own code whether you want to take an error-based or exception-based approach to handling problems in program execution. If you have personal experience with writing exception-based code in WinDev please post your comments! I'd also be interested to hear from anyone who habitually uses these options to implement customized error/exception handling. 

Interestingly, in Java the convention is the other way around - exceptions are generally situations you are expected to handle while errors are usually fatal. 

Indirection

Indirection is one of those things that keeps coming up in the discussions I have with WinDev developers, and always in the context of "man, is this cool." 

It's a simple concept (it only gets a single page in the tutorial) but it really is powerful. Indirection allows you to build the name of a control, a file item or a variable from a string expression. Think of it as a kind of late binding.

Here's an example from the tutorial that assumes you have a control called Name and a variable called CustName:

{"NAME",indControl} = CustName

The second parameter (indControl in this case) tells WinDev the type of object it's resolving.  Other indirection constants include:

  • indConnection
  • indFile
  • indGPW (GroupWare)
  • indItem
  • indLink
  • indPage
  • indQueryParameter
  • indReport
  • indVariable
  • indWindow

Clearly there's a lot of opportunity to write generalized, reusable code with indirection.