Error/Warning handling question

Hello

I have a question about error handling, or more precisely about warnings.
I'm
writing a small Tcl extension, that registers some new commands. One of them
is a new Tk-Widget, all the others are normal Tcl commands. The extensions
works perfectly without the widget, so it is more an optional feature. In my
init function, I check for Tk, and if it is available, the widget command is
created, otherwise not.

Since not creating the widget command is not an error, I don't want to
return
TCL_ERROR on [package require], but I want to let the user know, that the
widget command is not available, because of the missing Tk.

So what is the recommended way to get a warning to the user without
returning
an error? Writing to the console (don't like that), or returning the warning
in interp->result? And is there a common format for warning messages?

Thanks, regards
Stephan

On May 8, 5:58 pm, Stephan Kuhagen <s...{}nospam.tld> wrote:
> Hello
>
> I have a question about error handling, or more precisely about warnings.
> I'm
> writing a small Tcl extension, that registers some new commands. One of them
> is a new Tk-Widget, all the others are normal Tcl commands. The extensions
> works perfectly without the widget, so it is more an optional feature. In my
> init function, I check for Tk, and if it is available, the widget command is
> created, otherwise not.

Instead of warning the user, what about trying to create the widget
command only on-demand ?
Though I don't know the details, I suspect [autoload] allows to have
the behavior seen in TkCon when you type a widget creation command
before any [package require Tk]. If you do this (without the user
interface, just the late init), you'll have the additional benefit
that [package require YourExt] and [package require Tk] will be
permutable.

-Alex

Stephan Kuhagen wrote:
> [...]
>I'm
>writing a small Tcl extension, that registers some new commands. One of them
>is a new Tk-Widget, all the others are normal Tcl commands. The extensions
>works perfectly without the widget, so it is more an optional feature. In my
>init function, I check for Tk, and if it is available, the widget command is
>created, otherwise not.
>
>Since not creating the widget command is not an error, I don't want to
>return
>TCL_ERROR on [package require], but I want to let the user know, that the
>widget command is not available, because of the missing Tk.
>
>So what is the recommended way to get a warning to the user without
>returning an error?

I'd recommend splitting your extension up into two packages:
a main one that provides all the normal Tcl commands, and a
second one that registers the widget constructor command after
[package require]ing Tk and your main package.


--Joe English

On May 8, 11:58 pm, Stephan Kuhagen <s...{}nospam.tld> wrote:
> Hello
>
> I have a question about error handling, or more precisely about warnings.
> I'm
> writing a small Tcl extension, that registers some new commands. One of them
> is a new Tk-Widget, all the others are normal Tcl commands. The extensions
> works perfectly without the widget, so it is more an optional feature. In my
> init function, I check for Tk, and if it is available, the widget command is
> created, otherwise not.
>
> Since not creating the widget command is not an error, I don't want to
> return
> TCL_ERROR on [package require], but I want to let the user know, that the
> widget command is not available, because of the missing Tk.
>
> So what is the recommended way to get a warning to the user without
> returning
> an error? Writing to the console (don't like that), or returning the warning
> in interp->result? And is there a common format for warning messages?
>

Why not follow Unix design philosophy and do what it does in such
situations: don't treat it as an "error" or "warning" but simply give
users a way of checking if the Tk widget exists. A kind of simple
introspection. It's much simpler and serves its purpose. Besides, the
behavior is far less surprising: command line users would not expect a
GUI and would not expect a warning that the GUI cannot be created, and
programmers would not expect that simply requiring a package would
raise an exception or error condition.

A simple global variable should do:

$::myPackage::hasGUI

slebetman{}yahoo.com wrote:

> Why not follow Unix design philosophy and do what it does in such
> situations: don't treat it as an "error" or "warning" but simply give
> users a way of checking if the Tk widget exists. A kind of simple
> introspection. It's much simpler and serves its purpose. Besides, the
> behavior is far less surprising: command line users would not expect a
> GUI and would not expect a warning that the GUI cannot be created, and
> programmers would not expect that simply requiring a package would
> raise an exception or error condition.

That is kind of, what I want. It should not be an error. But I like to have
some notification to the user, when he loads the package. He will have
introspection anyway, since he can simply ask, if the command exists or
not. Nevertheless i like also some instant notification on [package
require].

But my question remains, if there is a convention of telling when something
is okay to use, but with some minor features missing. I remember a thread
some time ago about format of error messages and traces or something (can't
remember right now).

Stephan

Joe English wrote:

> I'd recommend splitting your extension up into two packages:
> a main one that provides all the normal Tcl commands, and a
> second one that registers the widget constructor command after
> [package require]ing Tk and your main package.

I thought of that first, but I don't like it... Maybe this will be an
option, when I "invent" some more widgets, so a second package makes sense.
Currently it is just a too small feature for that. It would not "feel"
good, to need another [package require] just for that simple command.

Additionally, I like to know how warnings should be handled. May there are
more situations, where a warning may be useful, but where an error would be
too much.

Stephan

Alexandre Ferrieux wrote:

> Instead of warning the user, what about trying to create the widget
> command only on-demand ?
> Though I don't know the details, I suspect [autoload] allows to have
> the behavior seen in TkCon when you type a widget creation command
> before any [package require Tk]. If you do this (without the user
> interface, just the late init), you'll have the additional benefit
> that [package require YourExt] and [package require Tk] will be
> permutable.

Sounds interesting, but then there would be a real error. Additionally, I
don't know how to achieve that elegantly. I think, it would mean, to
implement the command first without real functionality (so Tcl knows about
it) and then throw an error or warning on first use, when Tk is not
available? Hm...

Stephan

On May 9, 6:59 am, Stephan Kuhagen <s...{}nospam.tld> wrote:
> Alexandre Ferrieux wrote:
> > Instead of warning the user, what about trying to create the widget
> > command only on-demand ?
> > Though I don't know the details, I suspect [autoload] allows to have
> > the behavior seen in TkCon when you type a widget creation command
> > before any [package require Tk]. If you do this (without the user
> > interface, just the late init), you'll have the additional benefit
> > that [package require YourExt] and [package require Tk] will be
> > permutable.
>
> Sounds interesting, but then there would be a real error. Additionally, I
> don't know how to achieve that elegantly. I think, it would mean, to
> implement the command first without real functionality (so Tcl knows about
> it) and then throw an error or warning on first use, when Tk is not
> available? Hm...

This is exactly what happens to other Tk widgets. TkCon has a very
elaborate reaction (posting an alert with a choice to the user), tclsh
a much simpler one (unknown command). All you have to do is:

- register the widget creation command with autoload
- if it's called before [package require Tk], that's an error
(just like for canvas)
- if it's called after [package require Tk], install it and call
it on the fly.

Again, all this regardless of the order between the two [package
require]s of Tk and your ext.

-Alex