On 16/01/2022 04:57, Ruvim wrote:
> On 2022-01-14 17:35, dxforth wrote:
>> On 14/01/2022 17:29, Ruvim wrote:
>>> On 2022-01-14 03:06, dxforth wrote:
>>>> On 13/01/2022 22:37, Ruvim wrote:
>>>>>
>>>>> A dedicated linked list is only one of possible implementations.
>>>>> For example, a word list is a built in linked list that can be also
>>>>> used. But it can implemented even without any linked list!
>>>>>
>>>>>     here constant magic-exception
>>>>>
>>>>>     : exception ( sd.message -- n )
>>>>>       align magic-exception , here >r ," r>
>>>>>     ;
>>>>>     : message-by-throwcode? ( n -- c-addr u true | n false )
>>>>>       dup magic-exception here within 0= if false exit then
>>>>>       dup cell- @ magic-exception <> if false exit then
>>>>>       count true
>>>>>     ;
>>>>>
>>>>> In this simple variant we don't provide a method to find the throw code
>>>>> by a message, and the "exception" word shall not be performed when the
>>>>> current definition exists. But these limitations are not too difficult
>>>>> to mitigate.
>>>>
>>>> Interesting technique.  Since n is an exception I would just throw it
>>>> (e.g.
>>>> via ?ABORT).
>>>
>>> Formally n is a throw code.
>>>
>>> "?ABORT" doesn't accept a throw code, it accepts a flag and always uses
>>> -2 as a throw code.
>>>
>>> An arbitrary throw code can be used as the argument of THROW
>>>
>>>     s" test error message" exception constant my-ior
>>>     :noname my-ior throw ; catch message-by-throwcode? 0= abort" Err"
>>> type
>>>     \ it should print "test error message"
>>>
>>> The system can use "message-by-throwcode?" to show an error message when
>>> an exception was not caught by the user.
>>>
>>>
>>>> Personally I would have a hard time justifying EXCEPTION. YMMV
>>>
>>> I don't sure that namely this variant is worth standardizing. But I like
>>> it's key idea, since it provides an easy way to avoid the possibility of
>>> throw codes collision.
>>
>> It's not worth standardizing message-by-throwcode? because most users will
>> say the system should be the error handler of last resort i.e. if I THROW
>> a code generated by EXCEPTION and don't CATCH it, the system should display
>> the message and abort.
>
> Yes, you are right, but it's unrelated to standardizing
> "message-by-throwcode?". If no exception frame on the exception stack,
> the system should display the message regardless of this word. And by
> the section 9.6.1.2275 a system is already allowed to do it:
>
> | Otherwise, the system may display an implementation-dependent
> | message giving information about the condition associated
> | with the THROW code n.
>
>
> Also, I said nothing concerning standardizing the word
> "message-by-throwcode?". But I believe such a word should be
> standardized. It's useful to a user-defined text interpreter, to some
> libraries for logging, etc. And such a function is usually implemented
> by systems in any case.

EXCEPTION having stored away the string in a system-dependent manner,
there needs to be another word should the user need to retrieve the
information for any reason. This is getting complicated.

On Friday, January 7, 2022 at 2:07:28 PM UTC+1, Anton Ertl wrote:
> The recent discussions about throw codes and iors have inspired me to
> look at what various systems do.
Ok, my 2 cents for 4tH::
- 4tH has it's own I/O system, however, it can be emulated by a small library;
- If an exception is thrown, it is either caught or uncaught;
- If caught, the exception number is retained;
- If uncaught, the exception number is mapped to the system exception "Uncaught exception" UNLESS a system exception exists for this exception;
- Of the 30 system exceptions, only 8 conform to ANS-Forth (3-6, 9+10, 12+13);
- BTW, I'd love to have "37" - but it is outside the contiguous range of 0-29. So it is "14";
- Most of 4tHs native I/O words throw "14";
- The ANS FILE compatibility layer just checks for "non-zero" codes and makes it a "TRUE" flag;
- In 4tH, a TRUE flag equals "1";
- "1" maps to the vanilla "user defined exception" (all system exceptions are actually negative of course);
- Hence "1" is a valid throw value.

In the 30 year odd history of 4tH, the general "I/O error" has never posed a problem, since 4tH also reports the operand where it went wrong. But most often the cause is so trivial, even that debugging aid isn't required to solve it. IMHO the ANS FILE wordset is so b*** ugly, I've only used it once or twice for porting purposes. It would be quite simple to remove the "0<>" and let it return the true exception (and may be I'll do just that).

Bottom line is: ANY non-zero exception is just fine in 4tH for the reasons given before. The only reason I can think of when it's NOT fine is when you CATCH the exception and then manually evaluate it in some sort of CASE..ENDCASE without catering for an unlisted value.

Hans Bezemer