Here’s a question for the ‘good-practice’ experts:

What is recommended and what is essential for correct error trapping?
Take it that the reader knows the meaning of
On Error Goto 0|Goto Label|Resume Next
Resume [Next|Label]

The first question is on the need for a Resume. Quite a few authors omit one, such as PED page 393 ff. They are assuming that all error handling is cancelled on exit from a procedure. Does that have any implications for the program stack?

http://www.dailydoseofexcel.com/archives/2007/05/04/error-handling-template/
Dick Kusleika uses a Resume

The second question is on the use of GoTo in body code versus the desirability of one exit point for a procedure for cleanup.

———————————–

Style 1 – no cleanup code needed and there is no Resume.

Function SomeFunc
On Error GoTo OnError
{Body}
ExitFunc:
Exit Function
OnError:
{handling code}
End Function

———————————–

Style 2 – with Resume, without GoTo

Function SomeFunc
On Error GoTo OnError
{Body}
ExitFunc:
{cleanup code}
Exit Function
OnError:
{handling code}
Resume ExitFunc
End Function

———————————–

Style 3 – with Resume, with GoTo

Function SomeFunc
On Error GoTo OnError
{Body}
GoTo ExitFunc
OnError:
{handling code}
Resume ExitFunc
ExitFunc:
{cleanup code}
End Function

———————————–

Option 1
On Error GoTo ErrorHandler:
vValue = vGetAndReturnValue()

If an error occurs in the function, control passes to the calling routine’s error handler (but the description, etc. was created in vGetAndReturnValue()

Option 2
On Error Resume Next
vValue = vGetAndReturnValue()
if Err.Number 0 Then
Take appropriate action…..
End if

With this approach I can modify or add to the error message generated by vGetAndReturnValue or ignore it or take some other action.

FWIW, it was never a good idea to write volatile data to subdirectories under Program Files. And it looks like you’re admitting you misstated users needing admin priviledges to read files in their own Application Data folders. Maybe I’m a troll because I point out BS when I see it.

I haven’t used Vista, but if it works similar to XP for inhibiting access to various directories, it provides every bit as much security as worksheet-level passwords in Excel.

Where I work, many applications are accessed through Terminal Services. One of those applications is Excel. In Excel on Terminal Server, I can’t launch Explorer from VBA using a Shell statement, but I can launch it from Excel’s File > Open dialog by right clicking on a drive or directory and choosing Explore from the popup menu. Explorer doesn’t show the Terminal Server’s C: drive, but I can enter it in the address bar. I suspect it’d be no more difficult to explore Application Data in Vista.

I typically don’t respond to trolls, but just to clarify a few things I will.

The CSIDL_* constants are used with SHGetFolderPath and related shell functions available through the API. When you use the %ENVIRONMENT_STRINGS%, I believe this invokes a dll which interprets the string then calls shell32.dll. Using SHGetFolderPath cuts out the middle step.

AppData is the Microsoft recommended location for program data, whereas My Documents is recommended for user files. I don’t know where the JRE or Dr Watson store their logs, but I imagine DrWatson does event logging anyway, which is different.

My add-in is a COM add-in that requires admin privileges to install. Many users don’t know where the application’s folder is, and even if they did, Vista no longer permits writing to a Program Files sub-directory from an application with user-level permissions.

Also, it’s typically used in corporate environments where read/write access to AppData is permitted, but access to it via Windows Explorer is locked down. A savvy user could probably access the folder via the command line, but that would be a technical leap for many users.

In the end, I’ve decided to continue writing to AppData, but I will add a reader in my next release.

P.S. Dick – sorry for turning your blog into a forum.

I sometimes include a routine that prepares an email message to a configurable address after an error has been reported. I attach the text file to that msg.

The mail code depends on my client, if they use Outlook, it uses that, if they have Notes, I include that version of my code.

Presumably CSIDL_APPDATA points to the same directory as the environment variable %APPDATA%, or %USERPROFILE%Application Data.

No doubt this is an ignorant question, but user processes can write to that directory, and since it’s used in part to store user settings, users would need read/write access to it. Or are you saying that user-initiated processes have higher file system priviledges than users at a console command prompt, for example?

Whatever. Where does Dr Watson store its crash log files? If your users have Java Runtime Engines, where does it store its update log files? I suspect both are either in the directory pointed to by the %TEMP% environment variable or in subdirectories in it.

But if the only place from which users can open files is their My Documents folders, and the error logs are intended for users’ benefit, then write them to My Documents. Necessity would dictate your design, no?

Previously, I just wrote to the program directory (in Program Files), but since the launch of Vista I changed it to a program sub-directory under CSIDL_APPDATA. The problem, though, is that users cannot access this folder without admin permissions. In a corporate environment, this can be a hassle.

On the other hand, I hate to write this sort of thing to the My Documents folder, so I don’t have a happy solution either way.

Any thoughts?

All that said, in Stephen’s taxonomy I’m an optimist – I add error processing (pretty much as described) when it proves necessary. If I need to propagate errors back up the call stack then I Raise them. But I mostly write for local users, so I can afford it – if I was remote/disconnected then it would have to be a different story.

And as I look, PED is on top of the pile of books on my desk…