AGOL Notebook crashing with "import arcgisscripting"

[davedoesgis]

I am using an "Advanced" kernel Notebook in ArcGIS Online for Organizations. When I do an arcpy.management.Delete(<path>) on a file geodatabase, it is often locked, so Delete returns an exception of type arcgisscripting.ExecuteError, so I have a try/except block to catch this exception type and log a warning. This works great on my PC and a Windows server running ArcPy.

Running in an AGOL Notebook (AGOL for Organizations), however, just doing the import for this crashes the kernel. I get an error pop-up titled "Kernel Restarting" with the message "The kernel appears to have died. It will restart automatically." The browser window never restarts the kernel and it just sits there with a "Dead kernel" message and an icon with a spy-vs-spy bomb with a lit fuse. 

This is not just a Python exception, but rather is basically my whole OS crashing. Therefore, putting the import in a try/except block does not prevent this. Before I ramble on any more, has anyone seen this and gotten it working? 

---

Code samples and screenshots below. Check to see if the package is installed. 

import importlib
spec = importlib.util.find_spec("arcgisscripting")
print(spec)

The print statement produces this, so I believe the package is present: 

ModuleSpec(name='arcgisscripting', loader=<_frozen_importlib_external.SourceFileLoader object at 0x7fd50d03b490>, origin='/opt/conda/lib/python3.7/site-packages/arcgisscripting/__init__.py', submodule_search_locations=['/opt/conda/lib/python3.7/site-packages/arcgisscripting'])

I normally just import it, but even putting it in a try/except block fails. It also fails if I try to just import the specific exception class. 

try:
    import arcgisscripting  # THIS LINE FAILS
except Exception as ex: 
    print(f"Exception: {ex}")

When it runs the import (line 2), I get this pop-up: 

Despite what the error message says, I have never seen it restart itself in my browser tab, which just sits there with these ominous looking icons: 

Any ideas? thanks!

[Luke_Pinner · Accepted solution]

Use arcpy.ExecuteError instead:

import arcpy

try:
    arcpy.do_something()
except arcpy.ExecuteError as e:
    handle_error(e)

[davedoesgis]

Thanks, Luke. When the exception is raised, it is type arcgisscripting.ExecuteError. I can use that type to catch the exception in my ArcGIS Pro conda environment, but it crashes the whole kernel on AGOL Notebooks. It looks like arcgisscripting.ExecuteError inherits from arcpy.ExecuteError, or something like that. 

>>> try:
>>>     '''Some code that fails'''
>>> except Exception as ex:
>>>     ex
ExecuteError('ERROR 000464: Cannot get exclusive schema lock.  Either being edited or in use by another application or service.\nFailed to execute (Delete).\n')
>>>     type(ex)
<class 'arcgisscripting.ExecuteError'>
>>>     import arcgisscripting
>>>     type(ex) is arcgisscripting.ExecuteError
True
>>>     import arcpy
>>>     type(ex) is arcpy.ExecuteError
True

It would be nice if the exception were of the type that Esri actually intends for us to use. I usually catch the most specific type of exception I need to, but maybe just using the default Python Exception is easier if I don't need anything specific from this exception type. In this case, I'm just doing arcpy.management.Delete and it's failing because there are locked resources. 

[Luke_Pinner]

arcpy.ExecuteError is arcgisscripting.ExecuteError

print(arcpy.ExecuteError)
<class 'arcgisscripting.ExecuteError'>

Might be something happening when arcgisscripting gets imported in arcpy that causes a crash when you import it again in your notebook context. Worth reporting as a bug perhaps.

[davedoesgis]

I'm familiar enough with Esri's coding practices to know how convoluted things get with inheritance (or whatever this case is), but I really don't get why things from two entirely different packages are so intertwined. 

My code is part of a general tool I maintain at my organization. I don't necessarily know what my users are trying to do with it, so I wanted to provide as much information as I can about the error. That said, I don't have any specific use case for needing to know why it failed. Since the last thing I want is for my error handling to be a source of errors, I'm just going to catch it as the general Python Exception type going forward.