Sent from my iPad

On Mar 19, 2011, at 3:41 PM, "Rony G. Flatscher" <[email protected]> 
wrote:

> Sorry, after changing the code, it just occurred to me: "cond.program" is a 
> RexxStringObject and should never take on NULL as Jean-Louis reports, but 
> should rather be Nil()?
They most certainly can be null.  A null value indicates an absence of a value. 
 A RexxStringObject can
Never be .nil, since that would violate the type guarantee.

This is the appropriate value here.  The action of raise propagate is to use 
the current condition 
Information and reraise the condition in the caller's context as if the 
condition had been triggered at
The point of the invoking call.  Since the calling context in this situation is 
the bsf4rexx native code, 
There is no program information available.

Rick


> 
> Or with other words: is it possible that the RexxStringObject members in a 
> RexxCondition structure can be NULL?
> 
> ---rony
> 
> 
> On 19.03.2011 20:27, Rony G. Flatscher wrote:
>> 
>> Sorry, it should read "Nil" in the text rather than "NULL".
>> 
>> ---rony
>> 
>> On 19.03.2011 20:12, Rony G. Flatscher wrote:
>>> 
>>> In a bug report which relates to BSF4ooRexx Jean-Louis was kind enough to 
>>> look into the issue and came up with an analysis in 
>>> <https://sourceforge.net/tracker/?func=detail&atid=684730&aid=3205263&group_id=119701>.
>>> 
>>> According to his findings, the RexxCondition member "program" was NULL in 
>>> the supplied example. Before changing/adapting the code, I was wondering 
>>> whether it is truly possible for the "program" member to be NULL in the 
>>> case of a SYNTAX condition? 
>>> 
>>> What about the members "errortext", "code", "message", could they be NULL 
>>> as well in SYNTAX condition?
>>> 
>>> Is it safe to assume that the member "conditionName" will always have a 
>>> string value?
>>> 
>>> ---rony
>>> 
>>> P.S.: Here is the code that uses DecodeConditionInfo(...) to create a 
>>> Rexx-like error message which then gets forwarded to the Java side, where 
>>> the line causing the crash is highlighted in bold red.
>>> 
>>>     // allocates and creates a Rexx-like error message
>>> inline char * RgfCreateRexxlikeErrorInfo (RexxThreadContext *rtc, 
>>> RexxDirectoryObject condObj, const char * header)
>>> {
>>>     rtc->ClearCondition();
>>> 
>>>     RexxCondition cond;
>>>     rtc->DecodeConditionInfo(condObj, &cond);
>>> 
>>>     char *msg=(char *)RexxAllocateMemory( 4096 );
>>>     msg[0]=0;
>>> 
>>>         // format message according to exception type
>>>     if (rtc->SendMessage1(cond.conditionName, "EQUALS", 
>>> rtc->String("SYNTAX"))==rtc->True()) // SYNTAX condition ?
>>>     {
>>>                                     // will only use 1024 of it
>>>         char const 
>>> *line1=rtc->CString(rtc->SendMessage0(rtc->DirectoryAt(condObj, 
>>> "TRACEBACK"), "FIRSTITEM")) ; // first traceback line=error line
>>>        
>>>         char line2[2048]="";        // will only use 1024 of it
>>>         SNPRINTF(line2, 2048, "Error %d running %.512s line %d:  %.1024s",
>>>                             (int) cond.rc,       rtc->CString(cond.program),
>>>                             (int) cond.position, 
>>> rtc->CString(cond.errortext) );
>>> 
>>>         char line3[2048]="";        // will only use 1024 of it
>>>         SNPRINTF( line3, 2048, "Error %d.%d:  %.1024s", (int) (cond.code / 
>>> 1000),
>>>                                                 (int) (cond.code % 1000),
>>>                                                  
>>> rtc->CString(cond.message));
>>> 
>>>         SNPRINTF( msg, 4096, "%.16s%.512s:\n%.1024s\n%.1024s\n%.1024s", 
>>> DLLNAME, header, line1, line2, line3);
>>> 
>>>     }
>>>     else
>>>     {
>>>         SNPRINTF( msg, 4096, "%.16s%.512s: Rexx condition [%.512s] raised", 
>>> DLLNAME, header, rtc->CString(cond.conditionName));
>>>     }
>>> 
>>>     return msg;
>>> }
>>>       
>> 
> 
> ------------------------------------------------------------------------------
> Colocation vs. Managed Hosting
> A question and answer guide to determining the best fit
> for your organization - today and in the future.
> http://p.sf.net/sfu/internap-sfd2d
> _______________________________________________
> Oorexx-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
------------------------------------------------------------------------------
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
_______________________________________________
Oorexx-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Reply via email to