[MOAB-dev] Discussion on return type of MOAB routines

Paul Wilson wilsonp at engr.wisc.edu
Thu Jan 23 22:14:19 CST 2014 

Hi Tim,

On 01/23/2014 11:05 AM, Tim Tautges (ANL) wrote:
> The trouble is then where do you leave the extra information to be 
> picked up if the caller needs it.  We want to avoid things like a 
> last_error string on the instance, since that's not thread safe.
I'm imagining that you effectively repeat the same query that produced 
the information in the first place, but through a different interface 
that was setup to collect the interesting information.

This may be too expensive in general, but I thought I'd throw the idea 
out there.

Do you have a good sense of how common this would be?  You offered one 
use case, but are there many places in MOAB that offer more information 
to the calling function?

Paul
>
> - tim
>
> On 01/23/2014 07:54 AM, Paul Wilson wrote:
>> Hi all,
>>
>> Just catching up on this thread...
>>
>> On 01/22/2014 03:24 PM, Wu, Danqing wrote:
>>> Below is the summary of the discussions on return type so far. I 
>>> notice that how we handle special "non-success"
>>> condition (like TAG_NOT_FOUND) will affect our decision. Any 
>>> decision has its pros and cons. Maybe we need more
>>> opinions from other people.
>>>
>>> As for existing ErrorCode return type, Vijay and I prefer to use it. 
>>> Iulian also voted to keep it simple (enum/int)
>>> 1) This does not break any existing user code nor does it need to 
>>> change existing method signatures
>>> 2) According to Jed, PETSc returns error code because it is simple 
>>> and portable between languages
>>> 3) Benchmarking tests show that it has least overhead for function 
>>> return
>>> 4) No need to store any context explicitly, including error messages 
>>> that are already printed out in the stack trace
>>>
>>> Tim has some other reasons to return a class object instead of a 
>>> plain enum type
>>> 5) The overhead might be acceptable for MOAB
>>> 6) For non-success conditions, we might need extra information hat 
>>> can only come from the lower-level functions.
>> Since the calling function knows what it asked, couldn't this be 
>> addressed by a combination of:
>> * return one of a rich set of int/enum return codes
>> * API for querying the necessary information that is missing in a 
>> simple error code
>>
>> Cons:
>> * for cases in which there is necessary information, this would be 
>> slower than the other options proposed because of
>> another function call
>>
>> Pros:
>> * the calling function gets to decide whether it cares about (and 
>> hence bothers to query) the additional information
>> * there can be a richer interface for that additional information 
>> other than parsing a string
>> * a sufficiently rich enough set of error codes, may reduce the 
>> number of times that a calling function cares about that
>> info.
>>
>> Using Tim's tag_get_handle example (mismatched properties to 
>> tag_get_handle), if the return code was
>> MOAB_TAG_EXISTS_WITH_DIFFERENT_PROPERTIES (not a great choice, but 
>> illustrative), then there may be many cases where the
>> calling function just wants to handle this and move on, rather than 
>> query something like tag_get_props().
>>
>> Or am I missing something?
>>
>> Paul
>>
>>> Regarding 6), Vijay and I have similar opinion:
>>> Is that extra information in the returned class object really 
>>> necessary? An upper level caller, based on some context,
>>> usually knows how to handle a non-error condition. It can choose to 
>>> treat is as an expected error, and set it. It can
>>> choose to handle it and then return success. It can also keep it 
>>> unhanded, and return this condition code unchanged to
>>> its callers. Of course, the lowest routines, like tag_get_handle(), 
>>> will never set it as an error (because it does not
>>> know, totally decided by higher level callers), and just returns 
>>> this code as is. In this case, an ErrorCode still
>>> would suffice. Using an object to store any context explicitly is 
>>> probably not necessary here.
>>>
>>> BTW, according to Jed, PETSc never uses error handlers/return codes 
>>> for non-error conditions. It defines what should
>>> happen in that case and have a flag return if the caller needs to know.
>>
>>>
>>> Regarding returning a class object, there are three different options:
>>> 1) Use ostringstream as a member. This has more overhead according 
>>> to benchmarking tests. The size of the object is
>>> 360 bytes.
>>> 2) Use std::string as a member. This is slightly better than a). The 
>>> size of the object is 16 bytes.
>>> 3) Make the class a POD type, like C style struct, without 
>>> constructors. Then char* is used as a member. A global heap
>>> space should be allocated to store the string. The issue is how to 
>>> make this thread safe.
>>> For now, it is more likely that we will use either 2) or 3)
>>>
>>> Best
>>> Danqing
>>> ________________________________________
>>> From: Tautges, Timothy J.
>>> Sent: Wednesday, January 22, 2014 3:36 PM
>>> To: Vijay S. Mahadevan
>>> Cc: Jed Brown; Wu, Danqing; moab-dev at mcs.anl.gov
>>> Subject: Re: [MOAB-dev] Discussion on return type of MOAB routines
>>>
>>> On 01/22/2014 01:34 PM, Vijay S. Mahadevan wrote:
>>>>> It's entirely dependent on the application, same API call, same 
>>>>> return,
>>>>> different handling, and in some cases the application is a tool 
>>>>> inside the
>>>>> library.
>>>> If the calling function knows how to handle the error based on the
>>>> context i.e., fail with an error message or return with an error code
>>>> to be handled by upper level routines, an ErrorCode still would
>>>> suffice. Using an object to store any context explicitly is not be
>>>> necessary here IMO.
>>>>
>>> But it's information from lower-level functions that will go 
>>> missing.  Maybe that's not enough information to really
>>> worry about, esp. if we have a stack trace, but that's the reason 
>>> I'm saying we need this string.
>>>
>>> - tim
>>>
>>>> If you just want the control to augment the printed error message (in
>>>> fatal failure cases), use macros like SETERR that take a stream. Since
>>>> the program is going to exit due to the failure, each calling routine
>>>> can print its message and return appropriately without worrying about
>>>> the actual cost of storage of strings etc. For successful exits,
>>>> string remains null. The const char* version in my timing results will
>>>> be appropriate here.
>>>>
>>>> Vijay
>>>>
>>>> On Wed, Jan 22, 2014 at 1:26 PM, Tim Tautges (ANL) 
>>>> <tautges at mcs.anl.gov> wrote:
>>>>>
>>>>> On 01/22/2014 01:21 PM, Jed Brown wrote:
>>>>>> "Tim Tautges (ANL)" <tautges at mcs.anl.gov> writes:
>>>>>>> This depends on how often it happens.  In all cases, IMO, a success
>>>>>>> condition should result in nothing more than a
>>>>>>> POD-sized object (and I should add, no virtual table).
>>>>>>
>>>>>> vtables are just pointers like any other in terms of performance.
>>>>>>
>>>>> Sure but we still don't want that extra expense.
>>>>>
>>>>>
>>>>>>> If it's a non-success condition that is "expected" (normal 
>>>>>>> condition
>>>>>>> that's handled by the calling code), IMO this shouldn't print 
>>>>>>> anything
>>>>>>> by default.  If it's a non-success that's also unexpected, 
>>>>>>> printing is
>>>>>>> fine (including stack trace).
>>>>>>
>>>>>> I don't believe in expected failures.  I find keeping expected 
>>>>>> and error
>>>>>> conditions in-band leads to confusing control flow, but YMMV.
>>>>>>
>>>>> It's entirely dependent on the application, same API call, same 
>>>>> return,
>>>>> different handling, and in some cases the application is a tool 
>>>>> inside the
>>>>> library.
>>>>>
>>>>> - tim
>>>>>
>>>>>
>>>>> -- 
>>>>> ================================================================
>>>>> "You will keep in perfect peace him whose mind is
>>>>>     steadfast, because he trusts in you." Isaiah 26:3
>>>>>
>>>>>                Tim Tautges            Argonne National Laboratory
>>>>>            (tautges at mcs.anl.gov)      (telecommuting from UW-Madison)
>>>>>    phone (gvoice): (608) 354-1459      1500 Engineering Dr.
>>>>>               fax: (608) 263-4499      Madison, WI 53706
>>>>>
>>> -- 
>>> ================================================================
>>> "You will keep in perfect peace him whose mind is
>>>     steadfast, because he trusts in you."               Isaiah 26:3
>>>
>>>                Tim Tautges            Argonne National Laboratory
>>>            (tautges at mcs.anl.gov)      (telecommuting from UW-Madison)
>>>    phone (gvoice): (608) 354-1459      1500 Engineering Dr.
>>>               fax: (608) 263-4499      Madison, WI 53706
>>>
>>>
>>
>

-- 
-- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ --
Paul Wilson ~ UW-Madison ~ 608-263-0807 ~ cal: http://bit.ly/pphw-cal
Professor, Engineering Physics. ~ http://cnerg.engr.wisc.edu
Faculty Director, Advanced Computing Infrastructure


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6244 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.mcs.anl.gov/pipermail/moab-dev/attachments/20140123/447e7dfc/attachment.bin>

More information about the moab-dev mailing list