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

[Tim Tautges (ANL)]

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