You’re better off using Exceptions

Post by hello_moto » Mon, Feb 03, 2020, 6:41 PM UTC

abraxas wrote: post #19

pat2man wrote: post #4

When I moved to Rust the constant error wrapping or converting annoyed me. But after using it for a couple of years it turned out to be a huge blessing. Quite often I need to know exactly which error messages will be thrown so that I can do things like internationalization. While exceptions are quite convenient for prototyping for production I’m now firmly in the typed errors camp.

I don't know Rust at all but what you're talking about sounds equivalent to (much maligned) Java's checked exceptions system? I never understood the hatred checked exceptions received especially from the younger crowd. I still write Java at work and I still use checked exceptions whenever they indicate an error condition that must not be ignored by the client code. Many new to the project developers hate me for it in…

Post by mumblemumble » Mon, Feb 03, 2020, 6:43 PM UTC

_ZeD_ wrote: post #140

clon wrote: post #123

Earlier quoted context omitted.

> Well, in real code you are likely bubbling up an error in some way for your 404 Not Found and 500 Internal Error handlers to kick in. Which is essentially GOTO 404 A horrible idea that I see often in clever frameworks disobeying encapsulation and reasonable control flow in favour of magic

That is a wonderful idea. You don't need to deal with 404, 500 or other stuff, you just write for the "happy path". The framework deals with the rest.

Post by XMPPwocky » Mon, Feb 03, 2020, 6:44 PM UTC

seanmcdirmid wrote: post #129

iainmerrick wrote: post #111

Earlier quoted context omitted.

That’s a very, very common source of subtle bugs (often exploitable as security bugs) that are hard to spot and hard to test for. It’s good practice to design APIs to make race conditions less likely, by explicitly not splitting operations across multiple calls. Separating “exists” and “get” into separate calls is a disaster.

I would compare this to a map API: an access could throw if a key wasn't present, but you can check to see if the key was in there first anyways. As long as the map isn't being used concurrently, it isn't that much of a problem, and if it is being used concurrently, then you need a different design. In the former case, separating "exists" and "get" would be considered over-engineering. I guess databases and file syst…

Post by vikestep » Mon, Feb 03, 2020, 6:50 PM UTC

UK-Al05 wrote: post #118

ragnese wrote: post #92

In the article he posts a snippet of F# code: type Customer = { Id : string; Credit : decimal option } let average (customers : Customer list) = match customers with | [] -> Error "list was empty" | _ -> customers |> List.averageBy (fun c -> c.Credit.Value) |> Ok And argues that the F# programmer must conclude that all functions may throw because this function accesses the Option.Value without checking that it isn't…

Thats not how f# works normally. Normally you chain option operations with either binds, or you do a match(Which is exhaustive). Directly accessing the value is normally frowned upon. This guy either needed to make the option type go away, or filter out the None and pass that into average. List.choose could be used for this let average (customers : Customer list) = match customers with | [] -> Error "list was empty"…

  let average (customers : Customer list) =
      customers
      |> List.choose (fun c -> c.Credit)
      |> function 
         | [] -> Error "no customers with credit"
         | xs -> Ok (List.average xs)

Post by kstrauser » Mon, Feb 03, 2020, 6:57 PM UTC

reffaelwallen wrote: post #2

I love using exceptions as control-flow, Python makes it very easy, and it's really helpful. edit: grammer

  class OurExceptions:
      http_status_code = 500

  class DatabaseRecordNotFoundError:
      http_status_code = 404

  rows = db.select(...)
  if not rows:
      raise DatabaseRecordNotFoundError

  try:
      return call_view()
  except OurExceptions as exc:
      return response(status_code=exc.http_status_code)

  def some_view(object_id):
      obj = fetch_obj_from_db(object_id)
      return {"found": obj.name}

  def another_view(object_id):
      try:
          obj = fetch_obj_from_db(object_id)
      except DatabaseRecordNotFoundError:
          return {"error": "Not found. Try again later?"}, 404
      return {"found": obj.name}

  def change_password(userid, oldpass, newpass):
      # This raises an exception if the user can't be found
      user = get_user_by_id(userid)

      # This raises an exception if the old password is wrong
      verify_password(user, oldpass)

      # This raises an exception if the DB couldn't be updated,
      # perhaps because of a race condition with another request
      update_password(user, newpass)

      # By the time we get to this line, everything above has to have
      # succeeded, with zero manual error checking inside this view
      return {"result": "Password successfully updated."}