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
