Re: Auto-discard notification

On Mon, 09 Aug 2010 11:22:40 +0000
"Imposit.com - Webmaster" <[email protected]> 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:[email protected]]
> Gesendet: Montag, 9. August 2010 11:48
> An: [email protected]
> Betreff: Re: [Dspam-devel] 3.9.1-rc1: issue with classification user
> 
> On Mon, 09 Aug 2010 10:31:34 +0100
> Paul Cockings <[email protected]> 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
> > [email protected]
> > 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
> [email protected]
> 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspam-devel