Hi Øyvind,

On 09/12/2010 12:23 PM, Øyvind Harboe wrote:
> A general observation: wouldn't it be better to properly report
> the error at the failure site rather than try to interpret errors?
I always assumed that for a project like OpenOCD, which manages and performs
operations on a set of similiar objects (processors and debug interfaces),
consolidation of code and avoidance of duplication would be a fundamental goal. 
Enumerating a list of error conditions and handling them in common
infrastructure code seems consistent with that goal.
> Much less error prone, the error propagation is less than 100%,
> better info and less code.
Wouldn't it be a better goal to fix poor coding practices (not propagating
errors) than to just work around them?  And is it less code if a few lines are
eliminated from breakpoints.c, but every target checks the return code itself
and generates different messages that all say the same basic thing?  This only
confuses the conversation.
> To try to reconstruct some meaningful information about what
> happened from a 32 bit value yields pretty nonsensical error
> messages in general...
In general it can.  If you generalize too much across disparate objects,
abstraction, inheritance, and all that becomes impractical and a numerical error
code loses meaning.  But is that the case here?  Looking at the error codes in
target.h, all seem rather specific and have the same meaning on all targets. 
Probably the most vague is RESOURCE_NOT_AVAILABLE, but it's enough to let a user
know that if he wants another wp or hw bp, he needs to remove an existing one. 
(And currently some of the targets do log their own error in this case: "no free
breakpoint reg", "can't find an available comparator", etc).

Amyway, that's my two cents.  Wasn't thinking these deep thoughts when I
submitted the patch :-)  Just trying to fit xcale changes into the broader
framework.

Thanks,
Mike

_______________________________________________
Openocd-development mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/openocd-development

Reply via email to