Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!richsun!cweir From: cweir@cpg.trs.reuter.com (Charles Weir) Newsgroups: comp.sw.components Subject: Re: What is a reusable software component? Summary: How do we handle Errors and Configuration in Re-usable modules? Keywords: reuse error configuration Message-ID: <966@richsun.cpg.trs.reuter.com> Date: 1 Aug 90 00:22:00 GMT References: <27705@athertn.Atherton.COM> Sender: news@richsun.cpg.trs.reuter.com Followup-To: comp.sw.components Lines: 92 In-reply-to: paul@athertn.Atherton.COM's message of 25 Jul 90 04:29:24 GMT In article <27705@athertn.Atherton.COM> paul@athertn.Atherton.COM (Paul Sander) writes: > - Is this a reusable software component? Yes - a classic example of the kind of reusability that functional languages make easy. > - What are its characteristics that make it one? Simple interface. Use of reference parameters (structure pointers) as "magic cookies" where the meaning is not known by the caller to hide the meaning of the data. Use of function pointers to allow "call back" so that the module can interrogate the caller. [I should mention that all these are what is now thought of as Object-Orientation....] > - Anything else relevant to producing a good reusable component that is > reused ... Now lets get to the meat!! Here are a couple of issues that the example did not come to grips with... 1) Error and Exception handling. In Paul's example, exception handling was simple. He returns an error code. But what happens to that error code in the module that calls his code? Is is passed back - and where, finally, does the buck stop? Most modules end up needing some kind of error handling mechanism - and this can provide a real headache for reusable components:- A function supplied by the caller? perror(), followed by exit() - [I'm a C programmer]? Pass back a return code - and if so what? Each option is appropriate in some applications and contexts, and not in others. Yet the reusable module writer must choose one, since they are mutually exclusive. Hence (s)he looses potential customers for the reuse whichever option is chosen. 2) Configuration This is another embarrassment in re-usable code. Configuration parameters come in several forms:- Size parameters: If one application using a reusable module must run in a small space, it will want to make all structures (buffers, strings etc.) as small as reliably possible. A second application, though, has speed as a priority, and wants them as large as possible. Text strings: Some target users like messages like "DBLX fault at 0xfc0040": others must be treated more gently, or speak different languages. Magic items: Patterns on a screen, locations of files, etc. I can think of several ways to implement such configuration decisions:- Compilation constants (#defines) mean that the code must actually be changed for reuse. Parameters passed through a functional interface make the interface complex, and may mean that the calling application must "know" rather too much about the module. Configuration files provide a source on confusion and errors. Any option may be appropriate, but each cuts out potential for re-use. ---------------------------------------------------- I don't have any solutions, or even preferred options. I'm sure others have - any comments? - Charles -- Charles Weir, Rich Inc, 1400 Kensington, Oak Brook, IL 60521 Email: cweir@richsun.uucp uunet!richsun!cweir Phone: +1 708 574 7424 X2766