>
> >>>>> Peder Chr Norgaard writes:
>
> Peder> Using the November 1998 beta version of scotty 3.0.0....
>
:
>
> 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?
I would feel terrible. Even in the case of an improved exception catcher,
exception is not really what I want here, and it is truly clumsy. I mean,
an object with no default value is not an exception, it is a perfectly
normal case! In my analysis, all (OK, most of, haven't thought them all
through) the functions you mention above basically returns two-element
values, namely 1) a boolean (empty or not) and 2) a value (in the
non-empty case).
Considering Tcl's very limited type system, I suggest the most elegant
semantics would be the one used with Tcl's "regexp" command: let the
command deliver the "boolean" as the return value, and give the "value" in
a named upvar'd variable. If you worry about backwards compatibility, you
can use the current (ambigious) interpretation if the caller does not
specify such a named variable.
Then I can say
if {[Tnm::mib defval <object> def]} {
process $def
}
which is exactly what I want.
best regards
--peder chr.
Peder Chr. Nørgaard System Developer, M. Sc.
Telebit Communications A/S tel: +45 86 28 81 77 - 49
Fabrikvej 11 fax: +45 86 28 81 86
DK-8260 Viby J Denmark e-mail: pcn@tbit.dk
-- !! 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.