Re: [Help-smalltalk] Correct way to throw exceptions/errors from C to ST

[Roland Plüss]

On 04/07/2015 07:51 PM, Holger Hans Peter Freyther wrote:
> On Tue, Apr 07, 2015 at 06:24:15PM +0200, Roland Plüss wrote:
>
>> I sure can decide the return type. I just considered it quite quick and
>> easy if I could return an #int if I link to a function actually
>> returning an integer. I certainly could return nil but then I have no
>> idea what error really happened nor can I properly catch it (well...
>> besides ifNotNil: ). Since Smalltalk has already an exception/error
>> system why not using it? I don't like wrangling a language unless
>> there's no other choice.
> It is a matter of how much time you have. In most cases I don't
> think we want code like:
>
> Smalltalk code...
> C-code
> C-code
> Exception
> Smalltalk code...
>
> This will be problematic with native code.. we will do a longjmp
> through it or such. So what we can do is that the "next" execution
> context can be set once the process returns to Smalltalk. We are
> not many but if you want to implement it I am happy to help you.
Unfortunately I don't have time at the time being... at last not for a
Smalltalk VM endeavour. But once I'm done with the current work load
it's certainly an option. I could imagine something like having an
exception holder somewhere so if an exception happens the exception
object (which exists already in Smalltalk) is placed in a specific place
in the VM context. Once the cCall returns it can look if there is an OOP
stashed away and if so call in the current execution context
"ExceptionOOP signal". We would be in a valid Smalltalk execution
context and it would act like an exception signaled just in that place
from inside Smalltalk. This would be in my opinion a very small change
like 2 VM functions added: void gst_set_ccall_error(OOP exception) and
OOP gst_get_ccall_error(). Then inside the ccall function in the VM just
add a check to see if that OOP is set and get rolling. Theoretically
this could even be done in the Smalltalk side after finishing processing
the ccall by checking if the OOP is set in the VM and processing it.
Would be close to your ErrNo solution but instead of an integer it would
be an OOP instead.

>> And as far as I know I can't include any code into a <primitive>
>> declared method.
>>
>> I once did the trick with errno type error handling in a module I made
>> for Smalltalk but it's cumbersome to use and error prone.
> <primitive> will execute the Smalltalk code in case the primtive
> failed.  E.g. for the Array
>
> kernel/Array.st-    at: anIndex ifAbsent: aBlock [
> kernel/Array.st-        "Answer the index-th indexed instance variable of the 
> receiver"
> kernel/Array.st-
> kernel/Array.st-        <category: 'built ins'>
> kernel/Array.st:        <primitive: VMpr_Object_basicAt>
> kernel/Array.st-        ^self checkIndexableBounds: anIndex ifAbsent: aBlock
> kernel/Array.st-    ]
>
When exactly does a primitive fail and how can I trigger this from
inside a cCall? This might actually be abused for a little trick if
working right.

-- 
Mit freundlichen Grüssen
Plüss Roland

Leader und Head Programmer
- Game: Epsylon ( http://www.indiedb.com/games/epsylon )
- Game Engine: Drag[en]gine ( http://www.indiedb.com/engines/dragengine
, http://dragengine.rptd.ch/wiki )
- Normal Map Generator: DENormGen ( http://epsylon.rptd.ch/denormgen.php )
- Sowie verschiedene Blender Export-Skripts und Game-Tools

signature.asc
Description: OpenPGP digital signature