Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

DLL Talk / Address Of A Label

Author
Message
zog
16
Years of Service
User Offline
Joined: 13th Dec 2007
Location: Southport UK
Posted: 29th Jun 2008 20:20
The lack of error handling in DBPro is bugging me
( excuse the pun! ).
I think I would like to try and implement a classic basic error handling frame work for dbPro, but I am not sure it is possible.

I would like to implement the following commands

On Error Gosub LineLabel
On Error Resume
On Error Resume Next
ENumber - gets last error number
Error(n) causes an error

I have seen some old messages about getting the address of variables and functions, so I know it might be possible to do this, although unlikely.

I would like to obtain the address of a label and use it in a call to gosub.

Is this possible ?

Thanks for any help in advance

Jack Taylor

Jack Taylor
IanM
Retired Moderator
21
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 2nd Jul 2008 14:36
At this point in time, no it's not possible to get a label address. To be honest, I think you'd need compiler support to handle the jumping.

Your last command (to raise an error) is already available in one of my many plug-ins.

zog
16
Years of Service
User Offline
Joined: 13th Dec 2007
Location: Southport UK
Posted: 3rd Jul 2008 09:07
Thanks Ian, I didn't think it would be possible.
It would be nice to try and implement some sort of error handling in dbPro.
I going to go away and have a think about how to implement error handling.

By the way you did an amazingly good job managing to implement call back functions in dbPro.

I like impossible problems!




Jack Taylor

Jack Taylor
Diggsey
17
Years of Service
User Offline
Joined: 24th Apr 2006
Location: On this web page.
Posted: 3rd Jul 2008 18:48 Edited at: 3rd Jul 2008 18:50
@IanM
Could you not use the same method as for functions, but instead of searching for a function declaration at the return address, search for a 'goto' command, and return the address of the label.

You would use this code:
ptr = AddressOf() : goto label1

AddressOf would search starting from the return address until it found the code for the 'goto' and return the pointer that the goto command used

edit:
You would also have to find a way to skip the actual 'goto', so maybe have two gotos, the function returns the second goto it finds, and the first goto is just to skip the second one.
eg:
ptr = AddressOf() : goto skipgoto : goto label1
skipgoto:

Yuor signutare was aresed by a deslyxic mud...
Curious? CLICK HERE!
IanM
Retired Moderator
21
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 3rd Jul 2008 22:34
You're right - there are possibilities here that I've been thinking about since my post.

There are several separate problems to overcome:

1. Spotting the labels
You have come up with one solution - it requires a pre-processor, or a lot of manual setting up. There's a cleaner alternative that would use a combined pre/post-processor too. So it's doable, but not clean and requires a separate program to be run as a part of the compilation.

2. Jumping to the labels
Goto - easy-ish (remembering to keep the stack clean).
Gosub - Dunno - is there a separate gosub stack? If not then it's a slightly harder variation of the goto jump.
resume - where does the 'current' line start so you can resume it?
resume next - as per goto.
Call function - as per goto.

In all of the above, how is the stack affected by the error and what recovery is required? What about nested function calls or multiple gosubs?

3. Capturing the error before it triggers the runtime shutdown.
Doable - there's a section of error-handling code at the end of each compiled line where I can replace the code with my own.

4. Runtime discrepancies.
Who knows how much of a problem this is...
Load an object, runtime creates it and starts populating it, hits an error condition ... does it fully clean up the object and temporarily allocated memory,, or leave it all as-is, knowing that the program is going to shut down and will clean up anyway?

If you assume that the program is going to end, why would you write the code to clean up (more code = more bugs)? I would assume that you wouldn't.

Then we come along and try to change one of those basic assumptions ...


So, there are problems that are simple, some not so simple but doable, and some I can have no impact on at all. I'll continue to think about it, but I'm not sure it's a solvable problem without a lot of Lee or Mikes help (or access to the DBPro source code)

Login to post a reply

Server time is: 2024-04-20 01:37:11
Your offset time is: 2024-04-20 01:37:11