On 23 November 2013 17:42, Denis Kudriashov <dionisi...@gmail.com> wrote:
> Hi
>
> 2013/11/22 Igor Stasenko <siguc...@gmail.com>
>
>>
>>
>>> 2. instead of returning useful objects, FMOD returns error codes and you
>>> pass a pointer to receive the object.
>>>
>>> - The first consequence is that I have to wrap all the calls e.g. "self
>>> processErrorCode: self primCreate." where
>>> processErrorCode: anInteger
>>> anInteger = 0 ifFalse: [ self error: 'FMOD returned error code
>>> ', anInteger
>>> asString ].
>>> Is there a more graceful way to do that?
>>>
>>> i doubt so.. since it is library API which dictates you to use it in
>> certain way.
>> The proper error handling never hurts (except from causing extra code
>> bloat, of course :)
>>
>
> Is it good idea to override (or create new) #nbCall: method to handle
> library common logic? (when any library function returns error code)
>
of course, the #nbCall: is just a convenience method and meant to be
overridden if necessary.
nbCall: fnSpec
" you can override this method if you need to"
^ (self nbCalloutIn: thisContext sender)
convention: self nbCallingConvention;
function: fnSpec module: self nbLibraryNameOrHandle
And nbCallingConvention, nbLibraryNameOrHandle is there for override as
well.
A more verbose form is:
self nbCallout
stdcall;
options: #( - optDirectProxyFnAddress optAllowExternalAddressPtr);
function: #( NBBootstrapUlong HeapAlloc (ulong heapHandle , 0 ,
SIZE_T size) ) module: #Kernel32
But be aware though, that this code usually invoked once during code
generation,
and later no method code is invoked because it just runs a primitive
(primitiveNativeCall), and if it succeeds, it just returns with result,
without running a method's body.
So, nbcall can be changed/extended if you need extra thing at code
generation stage,
or you want to handle primitive error(s) differently.
But not for handling things like function return values (which happens to
be a library's error/success code).
--
Best regards,
Igor Stasenko.
