|
Bugzilla – Full Text Bug Listing |
| Summary: | Config calls which take a string can fail silently | ||
|---|---|---|---|
| Product: | ns-3 | Reporter: | Rajib Bhattacharjea <raj.b> |
| Component: | core | Assignee: | Mathieu Lacage <mathieu.lacage> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | normal | CC: | gjcarneiro, ns-bugs, tjkopena |
| Priority: | P3 | ||
| Version: | pre-release | ||
| Hardware: | All | ||
| OS: | All | ||
|
Description
Rajib Bhattacharjea
2008-04-09 16:34:07 UTC
(In reply to comment #0) > At the least, they need to output a warning message that says something like > "Config couldn't match the string XXX to an (attribute|trace source)". These > kind of output messages are enabled only if logging is enabled; it'd be nice to > have the messages that indicate a failure to be output unconditionally. The whole system works under the assumption that matching failures are not errors: it is impossible to tell the difference between a match failure due to a user typo or misunderstanding and a match failure due to the fact that the user requested a different trace source than the one present in a specific object. So, the bottomline is that yes, the current system makes it hard to debug match failures but there is no simple solution to that problem which does not suck. What is needed is something which returns a user-understandable report about what matched, what did not match and why and the debugging output is none of that. The hardest part here is first defining precisely the output you want to get. Implementing the error report generation is not especially hard once we have defined that. (In reply to comment #1) If a match fails on a certain string, the user should be notified of that. A failure is a failure...it is then up to the user to then debug and figure out the WHY (does he misunderstand the path, is it a typo, is he asking for wrong attribute/trace source, etc). I see them as two separate issues. I think this kind of alert would be very useful to our users. But, if you are suggesting deferring any such simple alert until a time when we have some kind of more generic reporting system in place, then that is fine by me. (In reply to comment #2) > (In reply to comment #1) > If a match fails on a certain string, the user should be notified of that. A > failure is a failure...it is then up to the user to then debug and figure out > the WHY (does he misunderstand the path, is it a typo, is he asking for wrong > attribute/trace source, etc). I see them as two separate issues. No, really, you have to understand that, from the point of view of the code, failing to match "/NodeList/0/DeviceList/0/TxQueue" against a WifiNetDevice instance because it does not have a TxQueue is just the same as failing to have the same string with a typo match against a CsmaNetDevice because of the typo. In the simple case where the user has not used wildcards, yes, one is obviously an error and the other is not. But, if the user has used wildcards and a mixed network (wired + wifi), then, the code has no way to know the difference between a match failure against a non-existent and correctly spelled attribute (which is _not_ an error when using wildcards) and a match failure against an existent but incorrectly spelled attribute.
> But, if the user has used wildcards and a mixed network (wired + wifi), then,
> the code has no way to know the difference between a match failure against a
> non-existent and correctly spelled attribute (which is _not_ an error when
> using wildcards) and a match failure against an existent but incorrectly
> spelled attribute.
I should have pointed out that this kind of problem is pretty common: regular expression matching suffers from the same problem: when you have a regex, the regex engine cannot tell which matching failures are errors from the point of view of the user and which are not. If there is a good regex debugging tool, I am not aware of its existence but, I would love to see one...
should this be marked WONTFIX? There are the Failsafe variants available if programmers want to enforce the match. (In reply to comment #5) > should this be marked WONTFIX? There are the Failsafe variants available if > programmers want to enforce the match. > The issue was with the Config::Connect* APIs, for which, from my understanding, there are no failsafe versions. To move forward, how about we deal with the simple case of Connect calls in which there are no wildcards; if one of these doesn't match a trace-source, a simple warning on the command line would be useful. |