Things that bothers me with arcpy and arcgis python api.

1710
8
02-21-2019 07:09 AM
PaalPedersen
New Contributor

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.

0 Kudos
8 Replies
DanPatterson_Retired
MVP Emeritus

I agree try-excepts are usually useless.  Complicating their use is that most people don't know how to devolve a trackback error.

May I offer up a humble missive on code formatting to help improve your day

/blogs/dan_patterson/2016/08/14/script-formatting 

JohnMDye
Occasional Contributor III

Perhaps this is just my own inexperience speaking, but I don't find try/except statements to be useless. The particular example that Paal Pedersen raises is certainly useless, but try/except in general, when used appropriately can be useful.

In GIS, we often can think of multiple ways to proverbially "skin the cat". Try/Excepts can be useful for getting the desired result through any one of those many processes. They can also be useful for handling very specific errors that one might encounter when performing a workflow.

While I agree with Paal that this particular example of try/except should be removed, because it is useless. I might go a step further and say that instead of removing the try/except statement, perhaps demonstrate how it can be useful for handling a specific error or getting the same result through a different process if a particular exception is thrown.

PS. No cats were harmed in the making of this post.

0 Kudos
DanPatterson_Retired
MVP Emeritus

glad to hear about the cat thing.

my comment was about the use of try-except blocks being used in place of accounting for logic issues in code.  If something is going to produce an error or an unexpected circumstance, that issue should be addressed rather than having the code report an exception.  I have seen lots of code use try-except blocks when simple checks could be used in their place... eg.  isinstance, hasattr amonst others.

JohnMDye
Occasional Contributor III

I agree with that. Try/Except is useful when used appropriately and I would agree that if Esri is going to have Try/Except blocks in their code examples, they should be demonstrating how to use that properly. There's definitely no point to the try/except blocks in many of the examples and it teaches new developers bad habits.

JoshuaBixby
MVP Esteemed Contributor

Just out of curiosity, can you share some links to examples where Esri is showing needless try/except blocks?

0 Kudos
JoeBorgione
MVP Emeritus

We use try-except blocks in nearly every administrative script we run during off hours.  We try a process and if it tosses an exception, we get an email with the exception/error alerting us.  For us, that's an effective use of try / except.  But if someone were to:

try:
   blah
   blah
   blah
except:
   pass

It's just bad form. Is that the sort of thing you are seeing?

That should just about do it....
0 Kudos
simoxu
by MVP Regular Contributor
MVP Regular Contributor

Good point. It's not only ESRI examples, haven't we seen enough useless error messages in all sorts of software applications (Some of the Microsoft error messages are particularly irritating...)?

I think the discussion should really boil down to this question: Does ESRI provide good Exception classes in its APIs? If it does,  then it's done its due diligence, and it's up to the developers to capture the more informative Exceptions. If it does not, there are not much a developer can do about it, then the API is not good enough in terms of elegancy.

I personally don't have much problem with ESRI exmaple codes, most of them are just code spinets to demonstrate a particular functionality of the API, and I guess their focus is not on the exception part.

Having said that, I have to confess I often copy and paste the example without refining the exception handling, it would be nice if they did that for me

0 Kudos
MKF62
by
Occasional Contributor III

I'm a little late to the party on this, but...

 I use try/except blocks where it's something the user has to fix on their end and it is something I cannot fix because I don't know the nuances in their data collection. For example, they submit to me a bunch of polygons that should be conicident with each other, but my script finds multiple large gaps (I fix small ones with the eliminate tool) between the polygons they have drawn. I cannot fix those boundaries because I do not know where those boundaries are supposed to lie; they do. This is something the user has to fix since I cannot, so I create a class for the error and create a specific error message telling them what they need to do. I don't think try/excepts are useless in all cases.

0 Kudos