|
On Tue, 9 Nov 2004 12:39:49 -0600, Joe Pluta <joepluta@xxxxxxxxxxxxxxxxx> wrote: > > From: Steve Richter > > > > it is also a violation of the principle of modularity. A proc/module > > should not know that 4 levels up is the driver CL at which all > > exceptions are caught. A module throws an exception back to its > > caller. It is the callers responsibility to promote that exception or > > to handle it. > > Ugh. Pontification from the High Mountaintop of Computer Science. > "Principle of modularity" is just a term, not an absolute. If I want to > define a point in my job structure where all exceptions should go, > that's JUST AS VALID as your decision to make each caller handle > exceptions. It is hard coding. Send an exception back to program "menu01C". No matter your religion that is a bad practice that does not contribute to bullet proof applications. > > Remember, Steve, it's a business decision, not a religious decision. > > > > So the degree of granularity is the Job? That is not an acceptable > > solution when you want to hide exception handling from the end user. > > Why should the user have to sign back on because my program failed? > > This also works at the AG level. I was making the point that it works > at the JOB level as well, alloeing you to intercept and respond to > system operator cancels, which is something no other operating system > can do that I know of. > > > > I dont think that is true and besides, that example limits the work of > > a destructor to memory management. > > Steve, what you think is no more valid than what I think, and my example > does not limit anything. > > > > What locks are released when the activation group ends? A module > > should not have to rely on an activation group boundary for it to > > function properly. When the module invocation is destroyed on the > > stack, that is when the destructors defined in the module should > > execute. What could be more simple than that? > > And you can do this, Steve. Simply register your destructors and call > them when the AG ends. The only thing not done here is that the > language doesn't automatically register the destructors, you have to do > that yourself. there is also the practical matter of one module in the application telling the AG shutdown module what has to be shutdown. If the "in transit" quantity in the inventory master is changed in the expectation of the code at the end of the module moving that quantity to the "received" column, how do you tell the catch all AG exception handler what it needs to know to undo or complete the transaction? What if a mutex is locked so that a module can safely use an IP port? How does the AG exception handler know the handle to the mutex and that the mutex needs to be released? > > Your arguing against the principles of modular programming. A module > > is a self contained unit that functions properly regardless of > > commitment control, activation groups, job exit points. Exceptions > > and destructors are what make that happen. > > Not true. I'm arguing against Steve Richter's interpretation of modular > programming. I can do everything you do (such as send an exception > message to the previous level) if I want, or I can do it to a defined > level. I can provide destructors and call them as needed. All of this > can be done, the language just doesn't force its particular > interpretation of the rules on me. Which is pretty important in a > multi-language environment. I really hate languages which think they > know how to program better than I do. > > Sorry, but my point stands: ILE does everything you need Steve, just not > the way you like it. We are going in circles. My experience is that my RPG code is a lot better structured because of my experience with C++. The problem is that because RPG does not have the features I mentioned I cant get as good results as I do with my PC work. -Steve
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.