Peder> Using the November 1998 beta version of scotty 3.0.0....
Peder> I acknowledge that the "Tnm::mib defval" command is not even
Peder> documented, so I cannot really expect it to be fully
Peder> implemented.
Peder> Nevertheless, it has been very useful to me, but today I
Peder> discovered that I had not thought it all through. The problem
Peder> is: How do one distinguish, using this command on an OCTET
Peder> STRING typed object, between "no default value" and "default
Peder> value = ''H"? Until now, I have stupidly just used the "string
Peder> length = 0" of the output of "Tnm::mib defval" to mean "no
Peder> DEFVAL". But this fails, of course, when the DEFVAL is ''H. And
Peder> there are a fair amount of those in the newer std MIBs, in the
Peder> SNMP-VACM MIB for instance.
Peder> I have looked into the code in tnmMibTcl.c, it really looks as
Peder> if it returns the same value (i.e. an empty string) in both
Peder> cases.
Thanks for pointing this out. This actually touches a more fundamental
question: What to do if you use a Tnm::mib command on something that
does not exist?
Historically, the mib command returns an empty string rather than an
error if you do things like:
Tnm::mib index mib-2
Tnm::mib description mib-2
Tnm::mib member mib-2
Tnm::mib status mib-2
Tnm::mib syntax mib-2
Tnm::mib type mib-2
Tnm::mib variables mib-2
In the defval case, it is important to distinguish between a
non-existing default value and an empty default value. However, the
same argument (but less obvious) can be made for the other commands
listed above. So the question is: Shall I change the implementation to
raise Tcl errors rather than empty strings in all cases where there is
no real value?
BTW, the reason why I prefered empty strings in many cases is that
Tcl's exception handling (mainly catch) is ugly and leads to clumsy
code. Its IMHO possible to extend catch so that it is much more
powerful and leads to better code:
catch {cmd} msg {
*err* {
# do something if the errorMsg matches *err*
}
finally {
# this is done everytime we catch an error
}
}
Such a catch extension would help to avoid ugly catch/if combinations.
[I guess I am off topic now...]
Back to the question: How to people feel about returning an error
rather than an empty string in cases a Tnm::mib command hits a
non-existing value?
Juergen
-- Juergen Schoenwaelder schoenw@ibr.cs.tu-bs.de http://www.cs.tu-bs.de/~schoenw Technical University Braunschweig, Dept. Operating Systems & Computer Networks Bueltenweg 74/75, 38106 Braunschweig, Germany. (Tel. +49 531 / 391 3289)-- !! This message is brought to you via the `tkined & scotty' mailing list. !! Please do not reply to this message to unsubscribe. To subscribe or !! unsubscribe, send a mail message to <tkined-request@ibr.cs.tu-bs.de>. !! See http://wwwsnmp.cs.utwente.nl/~schoenw/scotty/ for more information.