Tcl Source Code

I see that the [try] implementation has a
table of Tcl's built-in exception code,
duplicating the table already in the
[return] implementation.  Might be
worth factoring this out.

allow_comments - 1

- Checked documentation: It only handles exact matches, so it is consistent with the TIP
- Revised test cases, checking for the error case when using abbreviations.

So, this issue can be closed.

My code (I'm wholly responsible^Wto blame for the C implementation of [try]) accepted 'err' just because I couldn't be bothered to make it not do so. I'll have to apologize to Schelte for breaking his code, but it's for the best.

(And yes, more tests would be great.)

>Thinking more about it: I agree with Donal,
Of course, I meant Don!

The results show that this WAS a good
refactor:
- It discovered that the error messages
  used by the try command were not
  consistent with the return command.
- It discovered that the original try
  implementation did not match the TIP.

Thinking more about it: I agree with Donal,
and I recommend to keep it as is. Because:
- Tcl currently mainly accepts abbreviations in two cases:
      - option arguments starting with "-"
      - commands and ensemble subcommand,
        when in interactive mode
- If it was intended that try accepts abbeviations, there
  should have been a test case for it.
- Abbeviations only cause trouble when new return values
  are added: a new "error2" code whould start breaking
  Schelte Bron's code as well.
- TIP #329 mentiones:
The on handler allows exact matching against the exceptional return code (the integer value that would be returned by catch). The code may be given as an integer or one of the magic keywords ok (0), error (1), return (2), break (3), continue (4).
  it doesn't mention the possibility of abbreviations.
- Error codes are short, so I don't see much added
  value in allowing abbreviations.

Things to do:
- have a look at the current try documentation.
- add test case for [try], showing that use of
  abbreviations result in an error.

So, why don't we give the new function a flag argument, which
describes whether we accept exact abreviations or not?

I do *not* what [return -code] to start
accepting abbreviations.  If [try] needs
to do so, then I was mistaken about thinking
this was a good refactor.  Sorry.

allow_comments - 0

changes behaviour of [try]: now can't do this:
  try { ... } on err {} { puts Whoops! }
but instead need a full
  try { ... } on error {} { puts Whoops! }

Impacted Schelte Bron's code.

Added one further optimization: If the object type is indexType
already, it makes no sense to check if it is an integer. This
is indeed more in line with Tcl_GetBooleanFromObj, which does
every effort not to do useless conversions. Moved the function
to tclIndexObj.c, so we can make use of indexType.

Answer to dgp: I think that's the new function TclGetCompletionCodeFromObj already doing: It will convert the object to index type, which has indeed the integer value as its internal rep. There is no new object type needed for that, the index object type already does this. If the original string rep already is an integer, it will be converted to an integer object type. What more do you want? ;-)

Thanks, I think that's a step in the
right direction.

The thought I had with ObjType was
along the lines of Tcl_GetBooleanFromObj(),
so that the string values "ok", "error", etc.
could hold the corresponding integer values
as their internal reps.  Not critical at all to do,
but possibly a further future enhancement.

allow_comments - 1

Fixed in HEAD. Made it private function, as dkf suggested. Added
(trivial) integration with "try" command.

working on it

Make it private to Tcl for now. Like that we don't need to document it or put it in any stub table. (We can expose later if we want, but not all "parse" functions are exposed IIRC.)

Here is a first attempt at such a function. A separate ObjType is not very
useful, because the implementation is already covered by an integer
object and an index object. But a separate parse function (see patch)
could be useful to extensions as well.

Missing: documentation, integration with "try" command, addition to stub table.

Is this similar to wyat you had in mind?

File Added - 367871: tclResult.c.patch