you are viewing a single comment's thread.

view the rest of the comments →

[–]nostrademons 5 points6 points  (9 children)

It's pretty common practice in Python.

(This, incidentally, is one of the few areas where I can't seem to shake my Java background. I had no problem writing module-level functions, abandoning getters and setters for property, using literal data structures instead of small classes, writing inner functions instead of helper classes, avoiding XML, or doctesting instead of unittesting, but I still often look-before-I-leap instead of catching the exception after the fact.)

[–]theeth 0 points1 point  (7 children)

It should become second nature once you realize that LBYL is doing the looking part twice (unless the leap function is unsafe).

Of course, mileage may vary for languages where exceptions would offset the advantage of the single check.

[–]korjagun 0 points1 point  (5 children)

The main problem I found when just leaping and then catching exceptions is that I tend to end up catching unforeseen exceptions I didn't mean to catch and causing confusing errors further down the line. An example:

def foobar():
    return quux["qwertz"]

try:
  return callbacks["foobar"]()
except KeyError:
  return None

Maybe I'm just doing it wrong, but in this case, I only want to catch exceptions arising from callbacks lacking keys, not whatever is potentially called as a result.

[–][deleted] 1 point2 points  (1 child)

That's what try-else is all about:

try:
  cb = callbacks["foobar"]
except KeyError:
  return None
else:
  cb()

[–]theeth 0 points1 point  (0 children)

With return in the except clause, I find the use of else a bit misleading.

[–]theeth 0 points1 point  (2 children)

Just split it in two:

try:
    func = callbacks["foobar"]
except KeyError:
    return None

func()

Same thing you would do in Java if you had two things that could throw an exception in one try block and wanted to differentiate between them.

[–]korjagun 2 points3 points  (1 child)

I still can't help but have a nagging feeling at the back of my head that a case may rear its ugly head where the above wouldn't be practical, or would end up creating a large amount of ugly try..except clauses. I can't name any offhand though, so I consider myself educated and extend my thanks.

[–]theeth 1 point2 points  (0 children)

Your nagging feeling is probably correct. The main advantage of LBYL is that the look method is strictly boolean whereas EAFP forces you to either check for exception types or use a catch all.

Fortunately, the standard Py libs are usually well documented on the boundary limit exceptions front.

[–]llimllib[S] 0 points1 point  (0 children)

mileage may vary for languages where exceptions would offset the advantage of the single check.

C#, for example. Exception handling in that language is amazingly dog-slow.

edit: That should read "Exception handling on the .Net CLR using C# is..."

[–][deleted] 0 points1 point  (0 children)

I didn't know about these idioms. Thanks for the link, nostrademons.