RE: dRE: No Subroutines (was Re: Debugging many subprocedures)

Well, hope you didn't take it personal.

I am just saying we should use the message handling system IBM has given us. 
What I have tried to do with XVERRH is come up with a standard error handling 
method that is consist and I think that I have at least in my opinion done 
that. I use condition handlers before but using the throw procedure in the 
service program and modifications that saw on this forum was a lot easier. As 
far as message text, message text is message text. I have to create the message 
anyway and if I have to change the message, I can do so without changing the 
program. I just feel it is extremely important to use message id, substitution 
variables and second level help for all error messages. What would it be like 
if IBM just output a message saying "Error occurred in field". The biggest 
hassle is that the ADDMSGD is a royal pain to use. I have been trying to write 
a function to convert into XML and then pull into a GUI screen and allow GUI 
edit of the second level help so you could use the full length but haven't had 
time to get it finished. 

Again, please don't take all this personal. Just stating my opinion and typing 
fast. 

-----Original Message-----
From: John Taylor [mailto:lists@xxxxxxxxxxxxxxxxxxxx]
Sent: Wednesday, July 27, 2005 3:00 PM
To: 'RPG programming on the AS400 / iSeries'
Subject: RE: dRE: No Subroutines (was Re: Debugging many subprocedures)


 

> Look at XVERRH in my Trigger Mediator. I use the ERRH_Throw 
> to throw an error and use message definitions with second 
> level help with all the details. The error is thrown, and the 
> next level up either catches it or it lets it end with the 
> message containing all the details. Clean and easy. Don't 
> have to mess with coding error routines and next level needs 
> to know a lot more about an error than just the procedure 
> name. We have the best examples in the world when looking at 
> IBM messages. Most of the time clear and concise with all the 
> information they can pack in about the problem. 

Alan,

Passing the procedure name in the message data is an obvious work-around,
and one that I've resorted to in the past.

Lest you think me a newb, I coded my first version of your XXXX_throw()
procedure in V3R2 (1997?), and have been wrapping QMHSNDPM in pgm objects
long before that, so this is not unfamiliar territory for me. I completely
understand what I can and cannot do in terms of wrapping QMHSNDPM in a
procedure. 

There are times I consider it appropriate to call my XXXX_throw() procedure,
and other times when I find it more useful to call QMHSNDPM directly --
using a subroutine to clean-up the code.

I don't consider either technique bad. They both have their place in my bag
of tricks. So I wouldn't think to yell "hey Alan... why the f*k would you
waste space in your message text to pass a procedure name when the OS will
automatically handle it if you call QMHSNDPM directly?".


Regards,

John Taylor