I have several questions about error handling that I need cleared up. As
I understand it, any time one calls an API function the error stack is
cleared prior to the call being executed. Then, all the error that occur
inside of that API call are pushed onto the stack. This behavior happens
on all API functions, including (of particular interest) the H5?close.
So, what happens when one is creating one's own API-like functions. I
have two specific use-cases in mind.
In the first case, I have several functions which are wrappers around
H5Dread, H5Dwrite, H5Aread and H5Awrite.
These wrappers manipulate *and copy* the dataspaces and datatypes, etc.
If any errors occur, the function jumps to the end and closes any
handles that it opened. If I'm understanding what I'm seeing correctly,
when it closes these handles, the error stack is getting cleared.
Therefore, the error that actually caused it to exit is no longer
available to the caller.
In the second case, I have callback functions (for datatype conversion)
which also copy and manipulate some hid_ts. Again, the problem seems to
primary be with the close functions for the copies which execute on
function exit, regardless of whether it's a normal exit or an error exit.
What is the proper method, from outside the API, to handle these issues?
I have several questions about error handling that I need cleared up. As
I understand it, any time one calls an API function the error stack is
cleared prior to the call being executed. Then, all the error that occur
inside of that API call are pushed onto the stack. This behavior happens
on all API functions, including (of particular interest) the H5?close.
So, what happens when one is creating one's own API-like functions. I
have two specific use-cases in mind.
In the first case, I have several functions which are wrappers around
H5Dread, H5Dwrite, H5Aread and H5Awrite.
These wrappers manipulate *and copy* the dataspaces and datatypes, etc.
If any errors occur, the function jumps to the end and closes any
handles that it opened. If I'm understanding what I'm seeing correctly,
when it closes these handles, the error stack is getting cleared.
Therefore, the error that actually caused it to exit is no longer
available to the caller.
In the second case, I have callback functions (for datatype conversion)
which also copy and manipulate some hid_ts. Again, the problem seems to
primary be with the close functions for the copies which execute on
function exit, regardless of whether it's a normal exit or an error exit.
What is the proper method, from outside the API, to handle these issues?
Hello Jason!
I wonder what language you are using.
I'm using Delphi, and after each HDF5 API call I check for abnormal exit status. In case of error, I gather HDF5 exception info (stack) and raise native Delphi exception.
Delphi native exceptions are quite powerful (finalization sections, exceptions during exception handling) -- I do not have to do anything additional. I believe other contemporary systems (Java/.NET) also have solid exception handling facilities.
Best wishes,
Andrey Paramonov
···
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
I'm writing the 'API' in C, and calling it from LabVIEW. Most of the time I
make direct calls to the HDF5 library from LabVIEW and can collect the
errors properly. The problem occurs when I have these higher level
functions written in C that are called by LabVIEW. The functions need to do
clean up before returning, and that cleanup clears the error stack.
I suppose in the event of an error, I could gather the stack, call my
cleanup, and then push the stack back. That seems convoluted, but workable.
Any other ideas?
Jason
···
On Friday, December 19, 2014, Андрей Парамонов <paramon@acdlabs.ru> wrote:
18.12.2014 19:14, Jason Sommerville пишет:
I have several questions about error handling that I need cleared up. As
I understand it, any time one calls an API function the error stack is
cleared prior to the call being executed. Then, all the error that occur
inside of that API call are pushed onto the stack. This behavior happens
on all API functions, including (of particular interest) the H5?close.
So, what happens when one is creating one's own API-like functions. I
have two specific use-cases in mind.
In the first case, I have several functions which are wrappers around
H5Dread, H5Dwrite, H5Aread and H5Awrite.
These wrappers manipulate *and copy* the dataspaces and datatypes, etc.
If any errors occur, the function jumps to the end and closes any
handles that it opened. If I'm understanding what I'm seeing correctly,
when it closes these handles, the error stack is getting cleared.
Therefore, the error that actually caused it to exit is no longer
available to the caller.
In the second case, I have callback functions (for datatype conversion)
which also copy and manipulate some hid_ts. Again, the problem seems to
primary be with the close functions for the copies which execute on
function exit, regardless of whether it's a normal exit or an error exit.
What is the proper method, from outside the API, to handle these issues?
Hello Jason!
I wonder what language you are using.
I'm using Delphi, and after each HDF5 API call I check for abnormal exit
status. In case of error, I gather HDF5 exception info (stack) and raise
native Delphi exception.
Delphi native exceptions are quite powerful (finalization sections,
exceptions during exception handling) -- I do not have to do anything
additional. I believe other contemporary systems (Java/.NET) also have
solid exception handling facilities.
Best wishes,
Andrey Paramonov
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
