anze3db,
@anze3db@fosstodon.org avatar

Adding some error handling to the follow account feature at https://fedidevs.com.

Now that I've been writing Golang for a few weeks I am realizing that it's way to easy to forget about error handling in Python 😅

preslavrachev,
@preslavrachev@mastodon.social avatar

@anze3db yeah, it’s the same with every language that relies on throwing exceptions. When I was a full-time Java dev, the common understanding was that “someone else” would catch and take care of the exception, so there is no need to add explicit handling. Boy, was that wrong!

With Go, you take care of the error right away and forget. Yeah, it adds boilerplate, but with the right context and all, it will save you a** down the road.

anze3db,
@anze3db@fosstodon.org avatar

@preslavrachev to be fair, at least in Python there usually is someone else that catches and handles the exception for you. In this case the only change is the error message seen by the user.

It is scary that you can happily write code without even knowing that something could go wrong. The docs for this particular function never mention any possible exceptions 😱

preslavrachev,
@preslavrachev@mastodon.social avatar

@anze3db yeah, yeah - same in Java. If you use a framework like Spring or Quarkus, there is usually a dedicated catch-all exception handler. However, the problem with those is that they are very generic and until the an exception bubbles up, it may traverse 100s of methods. This makes debugging a real pain.

The other point you raise is even more valid - how can anyone write safe code expecting that something would run all the time and not ever throw an exception or error?

preslavrachev,
@preslavrachev@mastodon.social avatar

@anze3db one of the examples that really bugged me with Go at the beginning was calling an HTTP endpoint and deserializing its JSON output to a struct value. With Python’s requests lib, that’s more or less a single LoC. In Go, there are at least 3-4 places that can return an error, and rightfully so. Yeah, the requests call is a single line of code now, but sooner or later, problems will arise and I’ll have to wrap it with exception checks. Better do all of that from the start, I guess.

anze3db,
@anze3db@fosstodon.org avatar

@preslavrachev I still think it depends™️

If I'm writing a one off script I don't want to handle 4 different errors properly, I just want to call that API endpoint. Likewise if I’m writing an endpoint that only 10 people will actually hit every month. The odds of something going wrong are two low to warrant the extra work.

But when I have to run some code that will run every minute of every day that's where I want to know every single thing that could possibly go wrong in every line.

  • All
  • Subscribed
  • Moderated
  • Favorites
  • random
  • DreamBathrooms
  • everett
  • osvaldo12
  • magazineikmin
  • thenastyranch
  • rosin
  • tester
  • Youngstown
  • Durango
  • slotface
  • ngwrru68w68
  • kavyap
  • mdbf
  • InstantRegret
  • JUstTest
  • ethstaker
  • GTA5RPClips
  • tacticalgear
  • normalnudes
  • Leos
  • modclub
  • khanakhh
  • cubers
  • cisconetworking
  • megavids
  • anitta
  • provamag3
  • lostlight
  • All magazines