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

Reply via email to