RE: Style question: returning error values from functions
Yes, I was just about to suggest it to Richard. I think this is an under used language feature. Unfortunalty Scott designed the engine throws to require considerable parsing of the error variable to determine the problem so you need to handle the possibility of an engine throw. One advatage of throws is that they continue through the heirarchy until they are handled. I also find that scripts that use try/catch control structures are far clearer to read. Throw wins. Good discussion. Thanks. Is it possible to throw from an external? I haven't done any external development yet although as soon as I see some decent docs I'll probably jump in as I know some C. Regards Monte ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Style question: returning error values from functions
On Sunday, July 13, 2003, at 12:13 AM, Monte Goulding wrote: Is it possible to throw from an external? I haven't done any external development yet although as soon as I see some decent docs I'll probably jump in as I know some C. I'd be inclined to include a glue stack library with an external. It would handle the sugar coating for problems like passing data with nulls. In many cases it would do most of the work and use the external for getting to OS services. In this case, the glue library can throw for its own work and then throw for external errors flagged in globals. Dar Scott who didn't really answer your question ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
RE: Style question: returning error values from functions
Is it possible to throw from an external? I haven't done any external development yet although as soon as I see some decent docs I'll probably jump in as I know some C. I'd be inclined to include a glue stack library with an external. It would handle the sugar coating for problems like passing data with nulls. In many cases it would do most of the work and use the external for getting to OS services. In this case, the glue library can throw for its own work and then throw for external errors flagged in globals. Dar Scott who didn't really answer your question That sounds like a reasonable solution. Cheers Monte ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Style question: returning error values from functions
On Saturday, July 12, 2003, at 06:11 AM, Richard Gaskin wrote: Which approach do you prefer? One of these? Something else? I use these: 1. Reshape the semantics so there are no errors. 2. Throw 3. Value returned in referenced variable and success/fail (or related) returned. 4. Separate domain validation functions (used before instead of after) with, perhaps, #2 or #10 5. Callback (very rarely for functions; I'll ignore this) Sometimes #1 is like your error prefix but not always. For example, char 5 of abc returns a reasonable value, empty, rather than an error. In this approach what is reasonable depends on the function. Another #1 approach is to define a way to coerce parameters to the nearest closest value. A general scheme can be used for numbers that uses rounding and bounding as needed. The callback might reduce to changing a global error to a local error. These are also acceptable to me: 6. Global 7. Function like sysError() 8. Error returned in referenced variable in parameters 9. Use NaN, +Inf, etc for numerical functions (like #1) 10. Let the function throw error or return garbage; used with #4 Revolution built-in functions and operators use 1-3. Of #1 some return reasonable values and some coerce parameters to the function domain. I readily use throw in scripts for my own use. I also have used it in a library I will make generally available, and I'm thinking of changing the scripts so that they do not throw. Are people comfortable with throw? The value of functions is that you can use them in expressions. If you have to check after each use, then you lose the benefit. That makes #2 (throw) with perhaps #4 (data checking beforehand) more interesting. Dar Scott ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
RE: Style question: returning error values from functions
I readily use throw in scripts for my own use. I also have used it in a library I will make generally available, and I'm thinking of changing the scripts so that they do not throw. Are people comfortable with throw? Yes, I was just about to suggest it to Richard. I think this is an under used language feature. Unfortunalty Scott designed the engine throws to require considerable parsing of the error variable to determine the problem so you need to handle the possibility of an engine throw. One advatage of throws is that they continue through the heirarchy until they are handled. I also find that scripts that use try/catch control structures are far clearer to read. Cheers Monte ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Style question: returning error values from functions
Monte Goulding wrote: I readily use throw in scripts for my own use. I also have used it in a library I will make generally available, and I'm thinking of changing the scripts so that they do not throw. Are people comfortable with throw? Yes, I was just about to suggest it to Richard. I think this is an under used language feature. Unfortunalty Scott designed the engine throws to require considerable parsing of the error variable to determine the problem so you need to handle the possibility of an engine throw. One advatage of throws is that they continue through the heirarchy until they are handled. I also find that scripts that use try/catch control structures are far clearer to read. Throw wins. Good discussion. Thanks. -- Richard Gaskin Fourth World Media Corporation Developer of WebMerge 2.2: Publish any database on any site ___ [EMAIL PROTECTED] http://www.FourthWorld.com Tel: 323-225-3717 AIM: FourthWorldInc ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
