FPWERROR under VFP

[Brentds]

I wrote a FoxPro DOS app for a client 16 years ago. Converted to FPW 12 years ago. Now they want it updated to VFP for very little $$. Only the platform needs updating, not the app. The code should be okay with a few minor changes with the possible exception of FPWERROR which I used for error trapping.
Has anyone updated FPWERROR for VFP or written a similar error trapper for VFP? I know VFP has lots of new error stuff, but the old style should work fine with old code. There would be some new error codes when running under VFP that would just get passed over or be fatal with the old FPWERROR.

Any comments or suggestions?

Thanks,
brentds

 

[Olaf Doschke]

Foxpro Forums have merged, but there's still a seperate Forum for FPW and FPD, versions up to 2.6

I don't know if you perhaps talk about version 3.0, nevertheless I'd say it's better posted there: forum182

That said there are many ways to handle errors in VFP. As I fear this post will be deleted anyway, I'm not going into details. For a start you have the choice of general and local errorhandling via Error methods and via TRY..CATCH.

There's a decent whitepaper about errorhandling in VFP from Stonefield/Doug Hennig:

http://www.stonefield.com/techpap.aspx

Bye, Olaf.

 

[Brentds]

Thanks Olaf,
I am familiar with the options for error handling in VFP. However, I won't be able to include programing for the newer commands/methods in VFP for this legacy app. I need something that I can use under the ON ERROR command. That is, a procedure that will trap all errors, log them and either correct the problem or clean-up and exit the app.

Thanks again,
Brentds

 

[Dan Freeman]

Try it as is. Nothing changed with ON ERROR.

You're definitely NOT going to end up with the best-looking application but it sounds like you're aware of that.

 

[Olaf Doschke]

If you're migrating to VFP, you CAN mix it with the newer command and classes etc. Maybe you won't do it in the first place, but you CAN mix it with legacy code. Why do you think you can't?

First of all, try the code as it is, as DAN said ON ERROR is still there. VFP did never ever deprecate anything that is worth mentioning. It is however worth mentioning, that there is stuff much better than some legacy code. Nevertheless, migration is made easy and as Dan said, you'll end up with something looking ugly, but working.

I wonder why you ask, if you already know VFP. You seem to have, why not simply test? It now seems to me FPWERROR is simply a proecedure for error handling, not a special FPW command. You can still use it. I can tell you more, if I see the code or if you tell me about problems you have with it.

Bye, Olaf.

 

[Mike Lewis]

Brentds,

If I remember right, FPWERROR is just an error-handler that someone wrote and published. In other words, it's a procedure that should be called with the ON ERROR command. That command is still perfectly valid and has not been deprecated. It works just as it's always worked.

FPWERROR might itself contain out-of-date code, but that doesn't mean it won't work.

Why don't you test it for yourself. If it doesn't do what you want, by all means look for (or write) a replacement; otherwise, carry on using it.

My main point is that you don't need to change the overall structure of your error-handling. FPWERROR is just the specifice code that handles the error. Even if it no longer works perfectly, the basic strategy for error-handling is the same.

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro tips, advice, training, consultancy
Custom software for your business

 

[Brentds]

Thanks to all for your comments,

The main shortcoming of FPWERROR is that, while it traps all errors, VFP has many new error codes, for which there is no procedure written. I'm not sure which "new" FPW errors might occur with my old code. FPWERROR uses a DO CASE [error code] so the new errors would be handled by the OTHERWISE clause.
Indeed, I could write code to handle each of the newer error codes, or just abort the app on unknown errors, or possibly utlize the newer error handling commands. Its just that I want to do this as quick and simple as possible. As great as FPWERROR was for FP2.x, I thought, perhaps, someone had enhanced it by adding some procedures for the newer error codes. So far, it looks like no one has considered the ON ERROR/FPWERROR approach worth the effort and have moved on to the newer error handing commands.

thanks,
brentds

 

[Mike Lewis]

Brentds,

You're right that VFP has many new error codes, but you don't have to trap them individually. It's safe to assume that they are all basically program errors, and can therefore be treated in the same way (as opposed to situations over which the user has some control).

I suggest you just leave the error-handler in place and see how you get on.

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro tips, advice, training, consultancy
Custom software for your business

 

[Dan Freeman]

I agree with Mike. There are darned few "errors" that your code will be able to do anything about. You can't invent new disk space, add more memory, fix code typos, etc.

For most errors, log 'em and quit. (And that's what the otherwise on FPWError did, IIRC.)

Nobody has released a generic error handler for VFP because, frankly, it's *hard*. Error handling needs to be built into the object model of the application and only handed off to the generic ON ERROR routine if every object in the ooze says "not mine!".

Doug Hennig wrote an outstanding article outlining the methodology but it's a methodology that needs to be built in to the application's bone marrow, not grafted on after the fact.

Stick with what you've got. Adjust over time if needed.

 

[TheRambler]

Hi Brentds,

Craig Boyd wrote about error handling in his blog, see:
Professional Error Handling for VFP Applications