nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Better error handling on closed tables and geodatabases

PaulAustin

Would it be possible to extend the API to add an isClosed method to the Geodatabase and Table classes. Also isWriteLocked and isLoadOnlyMode on Table would be useful.

At the moment applications have to implement some other kind of reference counting to make sure they don't access closed geodatabases or tables or track if a table is locked or in load only mode.

Trying to access closed geodatabase or tables causes a core dump rather than throwing some kind of exception or error code. This makes developing applications tricky as apps just crash rather than getting a nice 'This object is closed' type message.

Trouver plus de publications taguées avec

Accepted answers

All comments

VinceAngelo

You should probably set the handle to null after you close it, to prevent this sort of coding flaw.

The Ideas site is the location for pitching enhancement requests.

- V

PaulAustin

Vince,

I'm more than aware of basic coding practices such as setting fields to null after they are used. In this can I have a complex application with multiple classes that could use the table. So it may get closed by one class but another still has a reference to it. I have a bunch of reference counting to avoid closing it while it is still in use and thread synchronization to prevent concurrent access. There was a bug in the reference counting that then caused the Table to be used once closed.

I'm also aware of the practice of using if statements to prevent referencing null pointers to prevent core dumps and return meaningful exceptions such as 'Cannot use a closed Table <name of table>'. I'd recommend that this be used in the FGDB API.

VinceAngelo

I understand what you are seeking. The issue is one of resources.

The file geodatabase API is based on the 10.x ArcObjects code to implement file geodatabases. It does not support multi-threading. Adding a great deal of trapping code (which was present in a different level of abstraction in ArcObjects) would alter the "Sergeant Friday" ("Just the code, ma'am, just the code") nature of the library, increasing size and decreasing performance, mostly to facilitate unsupported functionality. And in order to accomplish these changes, programmers would need to be taken off other (revenue-positive) development projects.

You can certainly submit requests for enhancements to the FGDB API through the Ideas site, but it doesn't seem likely that such enhancements would be adopted. Based on my observation of the process (which is not direct), it seems that enhancements to increase breadth of functionality (exposing existing geodtabase behavior) will be chosen over depth of functionality (error trapping for invalid pointers).

- V

PaulAustin

Any chance that the spec for the FGDB file format can be published so that the open source community can develop a library so you don't have to spend time maintaining non revenue generating code.

Rejoindre la conversation

Les membres connectés peuvent publier, suivre les mises à jour, et plus encore. Nouveau ici ? Inscrivez-vous gratuitement.

Liens rapides

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.