RE: Multi Occurrence Data Structure returned from a procedure

> From: Alan Campin
> 
> >> The best I've seen to date are Scott Klement's naming conventions
(for
> >> example, his error structure is dsEC).  I've co-opted them in some
of
> my
> >> stuff with a couple of minor changes.
> 
> You might want to look at my trigger mediator. I don't use error
> structures at all.

Actually, I was talking about the standard error structures (ERRC0100
and ERRC0200) used to call IBM APIs.  These structures are required for
many APIs.


> I used to do something like that but stopped developing
> that way and went back and rewrote my functions to use my current
system
> because if it comes back and the programmer is expected to do
something,
> they will absolutely not do it. Now if they make the call, put a
monitor
> around it, there is nothing I can do about that but that is on there
> shoulders. If they don't monitor, which most time programmers don't,
then
> they are going to get a detailed message stating the problem when the
> program blows.

This is an architectural point.  I don't know that I agree with the Java
technique of forcing them to monitor for an error over the OS/400
technique, which is to provide an optional error structure, and if they
don't use it, to then blow up.  That's actually a pretty nifty
technique.


> Over and over again I got calls from programmers. "Your
> stuff is not working" and then find out the program returned an error
> status but they never checked it so created a system that does not
expect
> them to do it.

And this is a philosophical one.  In my experience, there's an 80/20
rule in programmers as in most everything else.  About 80% of the
programmers are pretty good at what they do and try to do a good job,
while 20% just do it for the money, and expect everything handed to
them. 

We can talk about this another day, but my guess is it's not that
relevant to the RPG list <g>.

Joe