Re: What is the story with Server Busy

It doesn't affect other procedure levels Steve. It's effect is purely in the
current procedure and its call-frame on the stack. If you use 'On Error
GoTo -1' then it will cancel the fact you're "handling" an error. On the
up-side, this means you can set a new local error handler and prevent a
subsequent error being fielded by a different procedure level. On the
down-side, it means you cannot use the Resume statement (because there's no
longer any "active" error to resume from), but a GoTo can now be used with
the exact same effect. In other words, I'm afraid my second bit of air-code
wasn't entirely correct - the Resume should have been a GoTo:

ErrLab:
On Error Goto -1
On Error Goto NestedErrLab
...handle first error...
Goto somewhere

I'm afraid I don't know which version of VB this appeared in. I've never
really understood why it's so badly documented since I consider it to be
essential knowledge for any sort of sophisticated error handling.

Tony Proctor

"Steve Richfie1d" <Steve@xxxxxxxxxxxxxxxxxxxxx> wrote in message
news:44mmqhF2u1j9U1@xxxxxxxxxxxxxxxxx
Tony,

WOW! Be sure not to miss my comments at the end of this posting.

Sounds a nightmare Steve :-(

Not really. The software that came with my SMC wireless modem is worse!
If I leave that running, my computer runs slower, and slower, and slower
until after a day or so it finally grinds to a complete stop.
Fortunately, the driver works OK without the other software, so as soon
as it comes up, I quickly kill off everything but the driver. Most HP
printer drivers are unable to cancel a print in progress without some
sort of nasty after effects. Also, they are unable to print banner
sheets, handler forms changes, etc.

I just stick with it until things run cleanly, whereas others including
major vendors (like SMC and HP) would address the issue by just shipping
it. As I commented in an earlier posting, the REALLY interesting bugs
usually show themselves during testing.

I can now demo conversational speech I/O, but sometimes after a few
exchanges it will have some problem that I can fix with a keystroke, and
sometimes after it is long gone it somehow reappears with an error
message or something, but it does not seem to kill the system and it
does now demo.

I suspect that another week or so of beating on this thing will
substantially cure its present challenges.

Steve's 80% principle:
80% of your remaining problems are from just one thing.
When you fix that, 80% of your remaining problems will be from just one
thing.
When you fix that ...

Steve's one in three principle:
When you find something that is clearly wrong and which clearly explains
your present problems, then there is a one in three chance that fixing
it will indeed make a major improvement. Of course, even if it doesn't
help, that just means that it wasn't the biggest 80% problem.

Corollary to the above:
To fix 99% but not all of your problems, you must find and fix three of
the 80%ers, which means that you must find and fix approximately nine
things that are clearly wrong, each of which would explain your present
problems.

These principles seem to hold up in software, hardware (I'm an EE), and
medicine (I have also worked in medical research). Hence, if you are
sick, you must typically find and fix several different things that
clearly aren't right to effect a substantial cure. Doctors seldom ever
fix even one thing.

Hence, I just "turn the crank" on things until they work right.

On the subject of error-handling re-entrancy, you may or may not be
aware of
the following. I include a mention of it just in case it might help in
any
way: If an 'On Error' traps to a label in a given procedure, any
subsequent
error incurred at that label will be handled by error trapping in a
procedure further down the stack. This is true even if the error label
sets
its own 'On Error' trap! For instance, the following will not work:

On Error Goto ErrLab
...do some stuff...
Exit Sub

ErrLab:
On Error Goto NestedErrLab
...handle first error...
Resume somewhere

NestedErrLab:
...handle nested error...

At ErrLab, VB deems that an error handler is active, and so the next 'On
Error' doesn't have any effect. This is also the cause of one of the
most
common error-handling bugs - someone returning using a Goto rather than
a
Resume statement. Anyone who's done that would find that the procedure
would
not trap to the same error label again.

I have some of this sort of logic in my program, e.g. where I have the
name of a table or query, and try using it as various things until it
works for something. However, I just put a Resume to the next line at
ErrLab and NestedErrLab in your example to clear the stack as I go
along, so it works OK.

However, there is a poorly documented feature that allows the above code
to
work. There's an 'On Error GoTo -1' statement that clears down the
status of
"currently handling an exception", and allows the error handler to set a
new
error label, or even an 'On Error Resume Next'. For instance:

ErrLab:
On Error Goto -1
On Error Goto NestedErrLab
...handle first error...
Resume somewhere

Hey, maybe this could possibly be the cure for my *BIGGEST* continuing
pain in the ***! The damn stupid error handler design from Microsoft
absolutely INSISTS on passing errors to higher level routines. To avoid
multiple reporting of errors not to mention the many nasty side effects
of running errant subroutines multiple times, I must embed my present
subroutine calls within On Error statements! For example, I would write:

On Error GoTo 0
Call MySubroutine
On Error GoTo Error_Handler

to avoid the multiple error handling. Many of my present problems are
low probability, so it won't fail on subsequent re-runs of the problem
area. the Microsoft runaround means that I can't stop on the
problematical statement for debugging if any higher level routine grabs
the error, which REALLY slows down cleaning this thing up if I
accidentally miss putting the On Error statements around a subroutine
call. Of course, this gets problematical with long statements with
embedded function calls, IF statements with function calls, etc.

It gets uglier, because I definitely do NOT want to turn off error
handling in a primary event handling routine lest I risk having an error
in an exe and not knowing where it came from. At the top level, I use
the following that probably slows things down:

If IsExecutingFromIDE() Then On Error GoTo 0
Call MySubroutine
On Error GoTo Error_Handler

Perhaps a single On Error GoTo -1 statement in my central error handler
would short circuit the present multiple error handler executions so I
can get rid of my thousands of On Error statements around all of my
subroutine calls?! I suspect problems here because I will still need to
be able Resume to get back to a bad statement for debugging. Does it
damage the destination of an outstanding Resume statement in a higher
level routine, especially after subsequent On Error statements in lower
level routines like my central error handler?

Will On Error GoTo -1 actually work for this?

Also, is On Error GoTo -1 in all versions of VB like Erl seems to be?

Are there OTHER interesting undocumented features hiding in error
handling?

Steve Richfie1d
=====================
"Steve Richfie1d" <Steve@xxxxxxxxxxxxxxxxxxxxx> wrote in message
news:44kn4gF2lk1iU1@xxxxxxxxxxxxxxxxx

Hi Tony,


I did think a little more about your problems following the other
posts you've made in these groups. It feels like your complexity is

largely

the result of wanting to "handle errors where they occur", but without
wanting to stop event handling. This then gets you into re-entrancy

issues

with both error handling and event handling, as you've already found

out.

Yup, we are on the same page here.


Imagine your code as a single length of string, or more accurately a
'thread'. What you're doing is tying it in knots to make it deal with

all

your requirements, whereas it would be much easier to have multiple

lengths

of string. True multi-threading in VB is a bit of a black art, but
there

are

other ways to unravel your complexity. Why can't you defer the error
reporting by posting the details to a separate system, to be processed
out-of-synch with your events? This would leave your speech system to
recover quickly from the errors, and without any hold ups in the event
processing. Your event handler(s) could post as many details as

necessary

(e.g. all 'Err' object members, plus any contextual info) to the other
system, and then resume processing at a safe place. Your error system

could

then take care of the logging/reporting of those error details.

If I were starting from scratch with knowledge of the problems that lie
ahead, I probably would have opted to go the way you suggest - and
regretted it later! Now, though very complex I think I have gotten
everything working right with my present approach. What you suggest
would lose one VERY important capability - that of going back into the
code at selected points and changing things, single stepping, etc. You
see, I write pretty good code and review 100% of it before running it,
so most of the problems come from misunderstanding what the things I am
interfacing to are doing, and often/usually these misunderstandings
can't be clarified from what little information comes from an error
report once things have become so "wound around the axle" that VB
finally throws and error.

My present nightmare started with a simple 2-page program that presumed
that things worked as documented, that grew to over 50 pages of patches
and workarounds, all not counting a lot of supporting software. I had no
clue just how screwed up and just barely usable the SDKs and APIs that I
was using were. I think that most people would have "pulled the plug" on
this long ago after first realizing the rich assortment of traps that
were laid out for them. They say that fools rush in ...

Clearly, COM and the other "glue" that Microsoft provides for pasting
applications together has some SERIOUS shortcomings in the area of
real-time applications. Of course, Microsoft's defense is that "Windows
is not a real-time operating system" which is of course true, but that
wouldn't seem to give them license to make things even worse than need
be.

From my vantage point here, with the world's first demonstrable
conversational speech interface that WORKS, handling the tough cases
like silences, interruptions, etc., with the ability to carry on
ordinary conversations much like the fictional HAL-9000, EVERYONE,
including and most especially Microsoft and the makers of speech-related
software are running headlong in the wrong direction - SO wrong that I
am using quite old versions of the products that are part of this
because they are MUCH BETTER than the newer products!

In my youth I had an old vacuum tube oscilloscope, but I needed a better
'scope with triggered sweep and some other features for working on (then
vacuum tube and relay) computers. However, my meager allowance wasn't
enough to purchase such (then) leading edged equipment, so I modified my
old 'scope to provide what I needed. Surprisingly, most of the
modifications involved REMOVING components, so that the entire
modification resulted in a net enrichment of my junk pile! Clearly,
engineers had designed to a very specific requirement rather than being
free to do the best that they could do. The same seems to be the case at
present across the software world.

As I see it, much of this phenomenon is related to offshore development.
When you can't watch things close-up and casually talk with engineers
over the water cooler, the engineers feel compelled to provide what was
contracted for rather than something somewhat different that satisfies
the needs MUCH better. This can only reverse when the engineering is
done in the same building as the Chairman of the Board inhabits, be that
in Bangalore or Boston.

After throwing two recent HP printers into the garbage, I have "gone
retro" and we now use only pre-Y2K HP printers, mostly HP 970s. Before I
tossed them I dismantled them to figure out what was happening. Their
was NO wear or tolerance compensation as in older products, so your only
hope to keep them running would be to modify them every few months to
deal with the interim wear! Clearly, wear compensation was NOT on their
list of design criteria, and the foreign engineers didn't have the
experience to know to incorporate this. As a result, many models of the
present HP printers barely outlast their cartridges!

Anyway, back to error handlers. While VB thinks these happenings are
"errors" from its myopic point of view, they are REALLY usually
misunderstandings of some sort. Indeed, my paradigm/form looks like a
whimsical traffic citation, which provides 5 choices to choose among:

1. Guilty. You know you did something wrong, so just return from the
routine with a problem. EVERY routine is written so that prematurely
returning doesn't hurt whatever called it.
2. Not Guilty. You blame the computer, so On Error GoTo 0 : Resume to
stop in the program with full debugging and modification capability.
3. Internal Affairs. This immediately executes a Stop statement for you
to start hitting the F8 key to debug the error handler.
4. Paralegal. This composes and executes a Google query to see just the
responses to other postings with similar problems with similar
subsystems. Often, the application sits there for quite a while with the
error handler form showing while the problem is being researched,
starting by clicking this button.
5. Fail to Appear. This exits the program having the problem.

BTW, I am believed to have written the VERY FIRST Basic compiler with an
On Error statement for Remote Time Sharing Corp., which first saw
commercial service in 1970. My present error handler is a descendant
from way back then, having been through MANY other systems along the
way. Bill Gates was a user of that system when he was at Lakeside
School, and the ASR-33 Teletype seen in early pictures of Bill Gates and
Paul Allen was a loaner that I placed there. Lakeside School was only a
mile away from my home them, so I often stopped by to help the kids
there.

The fundamental misdirection of microcomputer technology: Microsoft was
created to make smaller computer systems from smaller (micro) computers.
However, the "mainframe" that Bill Gates and Paul Allen first learned on
at Lakeside School, that then also serviced many other high schools in
the Seattle area, was an HP-2116 with just 64KB of RAM and a 1 MHz
clock! It had a FORTRAN/ALGOL/BASIC all-in-one compiler and other
fantastic advances not seen since.

Microsoft has yet to discover many of the techniques that we used to
make so much run on so little.

Steve Richfie1d
=====================

"Steve Richfie1d" <Steve@xxxxxxxxxxxxxxxxxxxxx> wrote in message
news:44fb0mF1tu8gU1@xxxxxxxxxxxxxxxxx


Michael,



But then, your first error is your last, because it trashes the

real-time


processes so you can't proceed, at least not without so much
fiddling

that


you have destroyed what was then happening.


That's correct but you need to handle one error at a time. If I get
one
error and then 10 others I'm only interested in the first because

usually


the first caused the other 10.

My world isn't quite so simple. Errors are a way of life down deep
inside. Most errors are transitory or have some way of working around
them, which is now "all done by electric" except for the ones that I
haven't encountered yet, of which there must still be dozens. Here,
what
should be a transitory problem becomes a fatal problem without careful
handling. Often an apparently transitory error can have fatal side
effects, e.g. by disturbing some "unrelated" process (as if there is
any
such thing in a paging environment!). Hence, there is often a
cascading
sequence of errors, and attacking the first one is often not the best
approach, though it DOES tell you what started the cascade.

This project is teaching me a LOT about what should (and should not)
be
in a language for implementing really complex systems. I seriously
doubt
whether it would be humanly possible to originally write and debug
this
stuff in C/C++/C#, though the code could probably be converted to that
environment. Probably 20% of Dr. E1iza is concerned with handling
errors! I've had to adopt the policy that errors are to be handled
where
they occur and NOT passed on to other systems or calling routines,
which
has necessitated creating some powerful tools to deal with them where
they occur.

There has been a phenomenon knows as the "AI Winter" where for more
than
a decade funding has completely dried up for AI research. There is a
really good reason behind this. Professors, grad students, and
corporate
proof-of-concept projects all are limited to a few man-months of
effort,
which with the crude tools from Microsoft is just not enough time to
construct real-world practical AI systems. This is a tools and mindset
limitation and is NOT inherent in the AI problems at hand.

As I have mentioned in other postings, everyone seems to be running
headlong in the 180 degrees wrong direction. I must use decade-old
subsystems to do my work because the new stuff is completely unusable.
Even in cases like the C/C++ standard, obvious horrible deficiencies
in
the standard remain unfixed after being fully understood for more than
2
decades.

Have you ever met a standards person? Have you ever met a tournament
chess player? The members of both of these groups have the same neuron
broken! They are nearly all (in my decades of experience) egomanicial
jerks who are unable to take constructive criticism to improve their
efforts. This often proves to be their undoing.

In one tournament, my egomaniacal opponent was a game, a piece and
position ahead of me, when he reached to move his pawn and his shirt
sleeve caught the cross on his king and tipped it over. I snapped to
standing attention and announced "I accept your resignation" and
walked
out amid his screaming protestations. Of course, I knew full well that
the referees would converge on him, listen to his story, and order the
game to be played out. I visited the rest room, washed my face, got a
drink of water, and generally relaxed while I waited for a referee to
inform me to play the game out. You guessed it, I just LOVED the
similar
scene in the movie "The Hustler". This happened, and I returned to
play,
but my opponent was now SO excited that he played really horrible
chess
and I quickly wiped him out in both this and the next game to take the
match, which I would have almost certainly otherwise lost.



Hence, programming is just one annoying and relatively uninteresting

part


of this entire project.
The excitement lies in understanding enough about the world to
design
this, but transforming concept into reality is slower than playing
correspondence chess.

Have you tried gameknot.com for chess?

I prefer live, sweating, desperate egomaniacal people sitting in front
of me!

My 20 year old daughter also plays pretty good chess. She says that
she
can literally SMELL the fear when she beats one of these egomaniacs!
Once she has beaten them to get their attention, they usually turn
defensive, which of course is suicidal in chess. I haven't yet seen
one
return for a 3rd game with her.

THESE are the sort of people who are making the standards that are
screwing up the field SO much that work is being sent off shore.
Without
this strong negative force, the tools and methods would be there so
that
experts in the respective fields rather than full time programmers
would
be doing the work where it was needed - right here in America. You
would
be employed as an expert in a field that you understand rather than as
a
full time programmer.

Of course, what comes around goes around. I found some serous
deficiencies in the STRUCTURE of the RFCs (the Internet standards) and
attempted to contact several of the original authors to try to
engineer
a good solution. They were ALL UNEMPLOYED - apparently the victims of
the same offshoring that shortcomings in their efforts had helped
bring
on! These same structural deficiencies also provided the holes for me
to
do whatever I wanted despite problems that various subsystems had with
them, so that is what my NNTP client does - it works through the holes
in the standards until someone rises to restructure things.

Steve Richfie1d







.

Loading