On Mon, 09 Aug 2010 11:22:40 +0000 "Imposit.com - Webmaster" <webmas...@imposit.com> wrote:
> I would say a function for error Handling with an optional argument > errorcode where is needed. > The errorcode can be translated in the function to something human readable > Okay. So you are all for extending the current functions to return more then just plain success/failure? > on the other hand the idea slo the whole chain for the error is not bad. > openvpn do it that way > is a bit cryptic to read but if you read carefully you know exactly what is > wrong > This is the way how it is now implemented in DSPAM. > -----Ursprüngliche Nachricht----- > Von: Stevan Bajić [mailto:ste...@bajic.ch] > Gesendet: Montag, 9. August 2010 11:48 > An: dspam-devel@lists.sourceforge.net > Betreff: Re: [Dspam-devel] 3.9.1-rc1: issue with classification user > > On Mon, 09 Aug 2010 10:31:34 +0100 > Paul Cockings <ds...@cytringan.co.uk> wrote: > > > Stevan Bajić wrote: > > > > > > {function a} -[calling]-> {function b} -[calling]-> {function > > > c} -[calling]-> {function d} > > > | > > > +[calling]-> {function e} -[calling]-> {function d} > > > | > > > +[calling]-> {function f} > > > > > > > > > This is the reason I wrote "it is not that simple". > > > > > > > I love your explanations, so clear and easy to understand. :-) .. a > > true expert. > > > > If there was skill, time and motivation to change this, what would be > > the correct solution in your opinion? > > > "Correct solution"? It's hard to tell. Mainly because you can not just look > at one problem and say that this or that is the correct solution. You need > to look at the whole solution/code in order to say what would be the best > solution. > > > > 1. Stay with 'a bunch of functions' but add better error communication > > between functions > > > This will probably break the purpose of libdspam. > > > > 2. Rewrite the complete structure using something other than 'a bunch of > > functions' (aka Dspam 4 along with a LOT of other things half discussed) > > > That could be one way of solving that issue. I don't mean just rewriting the > functions but rewrite the way how errors are passed from one function to the > other. Maybe unifying the error codes so that functions don't just return > success/failure but do more. Another way would be to create something like a > stacked/logged error queue. Something where the calling "function a" could > then evaluate the whole calling path and then be able to print out that it > failed because of this and that and not be just limited to know that > "function b" has failed. > > > > Forgive me if the question has an obvious answer (in a developers eyes) > > > > > > > > ------------------------------------------------------------------------------ > > This SF.net email is sponsored by > > > > Make an app they can't live without > > Enter the BlackBerry Developer Challenge > > http://p.sf.net/sfu/RIM-dev2dev > > _______________________________________________ > > Dspam-devel mailing list > > Dspam-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/dspam-devel > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by > > Make an app they can't live without > Enter the BlackBerry Developer Challenge > http://p.sf.net/sfu/RIM-dev2dev > _______________________________________________ > Dspam-devel mailing list > Dspam-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/dspam-devel > ------------------------------------------------------------------------------ This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev _______________________________________________ Dspam-devel mailing list Dspam-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspam-devel
