paal.pedersengeodata-no-esridist

Things that bothers me with arcpy and arcgis python api.

Discussion created by paal.pedersengeodata-no-esridist Employee on Feb 21, 2019
Latest reply on Apr 17, 2019 by MollyKFoley

Comming from the field of geomatics to writing scripts and programs can be alot of fun. But sometimes we skip some fundamental parts of writing exceptional good utilities. And there is a particular weekness in arcpy and arcgis python api, and a lot of esri's script examples. And that is proper error handling.

Please when making cool and awsome logic, try to focus on throwing as many errors as possible, so that the user who don't fully know what the function do, can get a sence of what they are doing wrong, directly from the error message.

 

Don't even think about doing this:

 

try:

   100 lines of awsome logic.

except Exception as e:

   raise e

 

Here the try/except are completly nonsence. without the try/except the same error would be raised anyway.

Examples like this should be completely removed from every example given by esri. This causes a red glow on my forehead.

 

Instead make a lot of Cusom Error Classes if none of the default ones are suitable.

 

Example:

 

Class ParameterError(BaseException): # I

   pass

 

def some_function(arg1, arg2, arg3, arg=True, arg5='optional'):

   try:

      float(arg1):

   except TypeError:

      raise ParameterError('Parameter 1 must be numeric')

 

 

   try.

      something....

   except:

      raise ThisErrorInstead('A clear message to the user what went wrong')

 

We don't wanna see Error('999999 something went wrong')

 

I just have to get this of my chest. And i'm sorry if I did not search to see if there are other posts like this, before I started a new discussion.

 

Btw this forum should have a better way to format code inside the discussing. I tried using the sourcecode option.

Outcomes