Well, I guess I would say, positive points for including it in the discussion, but negative points for including it in the code. I think that the sentence from that doc which says "The standard and preferred way is to use the addError() routine" pretty well says it all...
Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice http://www.cintegrity.com
Well, I guess I would say, positive points forincluding it in the discussion, but negative pointsfor including it in the code. I think that thesentence from that doc which says "The standard andpreferred way is to use the addError() routine"pretty well says it all...
Well, I guess I would say, positive points for
including it in the discussion, but negative points
for including it in the code. I think that the
sentence from that doc which says "The standard and
preferred way is to use the addError() routine"
pretty well says it all...
Well, as I said earlier, the aim is to show mutiple ways, but then if we feel ome just makes more sense, then point that out. Not everyone may have implemented a form of formal error handling in their application, and so the alternative approach maybe a valid choice in that situation. The main thing is it's documented
Myself, I would focus on showing them how they could bolt on formal error handling to an application that doesn't have it now and gradually utilize it as opportunity presents.
Well, speaking of the error handling, let's talk about proException.p a little.
And, let me be frank up front about my aversion to the preprocessor, even though there are places where I have been forced to use it myself as the lesser of evils.
One piece I am curious about is why you have rather slavishly copied the Java exception handling? To be sure, it is the obvious model, but I would have thought that the history of ABL error handling was focused on the block and so it might have incented you to think in terms of block structured exception handling.
Something makes me nervous about raising STOP all the time ...
Any reason you did not provide temp-tables so that one could stack multiple errors?
It seems like there are an awful lot of entry points ...
Let me guess that this one preceded 10.1A?
PROCEDURE getUUID :
Purpose: Generates a Universally Unique Identifier.
Parameters: OUTPUT pcUUID
DEFINE OUTPUT PARAMETER pcUUID AS CHARACTER NO-UNDO.
pcUUID = GUID( GENERATE-UUID ).
END PROCEDURE .
The naming convention used in AutoEdge for program units, variables, and such seems to derive at least in part from the one used in John Sadd's whitepapers. Two questions:
1. Has this standard been codified in a document so that one can look at it rather than having to deduce it?
2. From an earlier exchange I got some indication that perhaps, now that AutoEdge was done, there might be some second thoughts about the standard, e.g., beXXX causes all be units to sort together rather than the various units associated with one entity. Is this more than a niggling doubt in the minds of isolated developers? Does anyone have a new set of proposals?
After some distraction, I am now back ready to do a bit of code reading. Is there an interest and willingness on the part of PSC to engage in a bit of "code review"? I.e., to discuss why certain design choices were made, what alternatives might have been considered and discarded, whether a particular alternative was considered, what advantages and disadvantages one might see, etc.
I think this would be illuminating to a lot of us.
1. Has this standard been codified in a document sothat one can look at it rather than having to deduceit?
1. Has this standard been codified in a document so
that one can look at it rather than having to deduce
There is a programming standards document available within the AutoEdge documentation in the Documentation > Project directory.
Let me guess that this one preceded 10.1A?PROCEDURE getUUID :/*Purpose: Generates a Universally Uniquee Identifier. Parameters: OUTPUT pcUUID Notes: */ DEFINE OUTPUT PARAMETER pcUUID AS CHARACTER NO-UNDO. pcUUID = GUID( GENERATE-UUID ).END PROCEDURE .
Purpose: Generates a Universally Unique
DEFINE OUTPUT PARAMETER pcUUID AS CHARACTER
No this is not pre-10.1A. It uses the new 10.1A language features to generate a global UUID.
Got it. Thanks.
What about the "If we had it to do over again" aspect?
My point is that with 10.1A this becomes trivial and a language built-in so I was guessing that the procedure preceded 10.1A and originally contained some workaround code to imitate what the built-in now does. Then, when you got the built-in, it replaced the body of the procedure.
Nothing significant. This is exactly the way I like to code when I expect something to be coming down the line so that minimal changes are necessary to switch over. I was just amused by how trivial the procedure became.
Personally, I would always wrap a GUUID() in a function or procedure all - that way if there's anything else that needs to be done at the same time the ID is obtained, it can be.
OK, I've been through the standards doc. My compliments that one actually exists and even seems to have been followed. I was originally thinking to have some give and take here, although I was first hoping to get the AutoEdge folks to make some comments on what they might decide to do differently, but it seems to me that the initial response might be a bit lengthy. What about the idea of converting it to a PDF and then I could add annotations and post both versions on OE Hive? I think that would be interesting.
There is a lot of it that is minor questions of taste, but a few points which I think are more substantive and "chewy", i.e., actually worth discussion.
Got it. Thanks.What about the "If we had it to do over again" aspect?
We're tried to address some of the 'If we had to..' in the 'Lessons Learned' sections in the supporting sample documentation which can be found in each of the OERA sub-categories under the AutoEdge category (http://www.psdn.com/library/kbcategory.jspa?categoryID=298).
This is not in the download materials?
I'm not readily finding it at that link?
While I am interested in the question generally, this specific one was about the standards.