undefined | Better HN

0 pointsbedobi2y ago0 comments

The problem with that is you lose all ability to understand or control what a given endpoint will return in any given situation

> I have no specific error handling for the given problem

then pass it on and decide what to do with it at the system boundary

in the db:

fun getUser(uuid: UUID) : Either<Error, User>

middle layers: pass around the either, you can map, flatmap etc on it to chain it with other computations there

then in the resource layer

return user .fold({ error -> when(error) { is DbError -> HttpResponse.InternalServerError() is UserNotFoundError -> HttpResponse.NotFound } }, { user -> HttpResponse.ok(user) })

Then, at every layer, each method explicitly says in the method signature what it returns. There’s no need to look around each and every line of every method in every layer, or in the framework, or some global exception handler, to figure out what will happen. Developers can tell from a glance at the resource method what the endpoint will return for each outcome, in context.

Things like being unable to communicate with the DB or not finding a user are not exceptional, they're entirely expectable when you're calling a db to look for a user and should be modeled accordingly.

0 comments

The_Colonel2y ago

> The problem with that is you lose all ability to understand or control what a given endpoint will return in any given situation

Why? In the simplest (but pretty common) case it's:

- successful response

- generic error message

> then pass it on and decide what to do with it at the system boundary

Yes, but if in 99% of cases I only pass it on, it's just visual noise. Noise you become blind to, and it loses meaning.

> Developers can tell from a glance at the resource method what the endpoint will return for each outcome, in context.

They can't really because you end up with some very generic error type anyway. Any typical service can have IOError, DBConnectionError, SQLError, OutOfMemoryError, StackOverflowError plus many other application specific errors. You end up with bulk of your methods returning Either<Error, Something> which is then meaningless.

WirelessGigabit2y ago

It feels like you're trying to use Exceptions as a way to steer your logic, otherwise why would you need to know why an operation failed to such detail?

Your controller method cannot act differently on a DBConnectionerror or OutOfMemory error.

Not to mention that exceptions cause developers to use them as control flow mechanisms.

For example searching a user by id. If the database returns 0 records, is that reason to throw an exception? Well, doing result[0] results in IndexOutOfBounds due to result being [].

But the reality is that the user not being there isn't exceptional. Typos are common. By using Result<T, E> or Either you enforce the developers to think more about their flow. One can write the method like this:

   fn find_by_id(id: usize) ->Result<UserResult, Error> -> {
       let raw_db_result = db.search("SELECT id, first_name, last_name FROM user WHERE id = ?", id)?;

       match raw_db_result {
           None => Ok(UserResult::NotFound),
           Some(r) => {
               let only_user = r.ensureOneResult()?;
               let user = mapDBUserToUser(only_user);

               Ok(UserResult::User(user))
           }
       }
   }

What about Error? Reality is that I don't really care. Error doesn't contain anything that is actionable. Either the whole chain succeeds and returns a valid result or the Error. The caller wants to find a user by id. There is one, or there isn't. All the rest is just errors that they'll pass on too. And in the end they get logged and result into Error 500.

A 404 is actually a valid result.

Now, if I were to use a throw new UserNotFoundException() for no user found you end up with generic try catches catching too much. And now someone needs to go and take it all apart to identify that single Exception that they want to deal with separately.

Whereas if I want to add a state in my enum the callers _MUST_ update their code due to how Rust works.

The_Colonel2y ago

> otherwise why would you need to know why an operation failed to such detail?

I'm not defining the errors like DBConnectionError or OutOfMemoryError - it's the framework/platform which defines them and throws/returns them.

> But the reality is that the user not being there isn't exceptional.

That depends. In some contexts it is not exceptional (getting user by ID given as an argument to webservice), in that case using Maybe type is great. In other contexts it is very much exceptional (e.g. signed JWT refers to a non-existing user) and throwing Exception makes more sense.

> What about Error? Reality is that I don't really care. Error doesn't contain anything that is actionable. Either the whole chain succeeds and returns a valid result or the Error. The caller wants to find a user by id. There is one, or there isn't. All the rest is just errors that they'll pass on too. And in the end they get logged and result into Error 500.

Which is the same as exception. But now you have this visual noise of something you claim you don't care about. An unchecked exception makes this irrelevant noise go away.

> Now, if I were to use a throw new UserNotFoundException() for no user found you end up with generic try catches catching too much. And now someone needs to go and take it all apart to identify that single Exception that they want to deal with separately.

    try {
        ...
    }
    catch (UserNotFoundException e) {
        // handle ...
    }

I'm catching exactly the exception I want. Where I'm catching too much? Where do I need to take it apart?

(This particular example of exception usage is bad, though, as it smells of exception control flow. Here using Maybe type would be better)

> Whereas if I want to add a state in my enum the callers _MUST_ update their code due to how Rust works.

Which is good for some cases where the enum describes "business" cases.

But it is pretty bad for truly exceptional cases (which are unlikely to be handled anyway). Library adding a new exceptional case will break its clients, which seems like a bad trade-off (again, for truly exceptional cases).

1 more reply

arcbyte2y ago

Actually, I have some java code that handles OutOfMemoryError when I do image resizing. Of the image is so big that the decompressed versión can't fit in half a gig of memory (which happens) then I fall back to some crude subsampling to size it down. It's unnoticeably less pretty but works is how o handle OutOfMemoryErrors in a specific scenario.

smallerfish2y ago

Or Kotlin's approach:

   fun getUser(userId: UUID): User?

You cannot treat this result value as a `User` in code that calls this; though, once you null check it in your service layer, you can pass it on as `User` in the not-null branch. Null is nothing to be afraid of if the language forces you to declare nullability and deal with it.

1 more reply

bedobiOP2y ago

WirelessGigabit gets it. That last fact is huge - functional error handling forces callers to handle (or pass on) exactly what can go wrong, no more, no less. (unlike exceptions)

1 more reply

bedobiOP2y ago

You're describing the problems with exception, not using Either... When using Either, you never fold on those errors individually... Anyway, it's clear we're not going to agree, and you win, since so far the industry is still stubbornly clinging to exceptions, despite them being a failed feature in every language they're in.

j / k navigate · click thread line to collapse

0 comments

The_Colonel2y ago

> The problem with that is you lose all ability to understand or control what a given endpoint will return in any given situation

Why? In the simplest (but pretty common) case it's:

- successful response

- generic error message

> then pass it on and decide what to do with it at the system boundary

Yes, but if in 99% of cases I only pass it on, it's just visual noise. Noise you become blind to, and it loses meaning.

> Developers can tell from a glance at the resource method what the endpoint will return for each outcome, in context.

WirelessGigabit2y ago

It feels like you're trying to use Exceptions as a way to steer your logic, otherwise why would you need to know why an operation failed to such detail?

Your controller method cannot act differently on a DBConnectionerror or OutOfMemory error.

Not to mention that exceptions cause developers to use them as control flow mechanisms.

For example searching a user by id. If the database returns 0 records, is that reason to throw an exception? Well, doing result[0] results in IndexOutOfBounds due to result being [].

   fn find_by_id(id: usize) ->Result<UserResult, Error> -> {
       let raw_db_result = db.search("SELECT id, first_name, last_name FROM user WHERE id = ?", id)?;

       match raw_db_result {
           None => Ok(UserResult::NotFound),
           Some(r) => {
               let only_user = r.ensureOneResult()?;
               let user = mapDBUserToUser(only_user);

               Ok(UserResult::User(user))
           }
       }
   }

A 404 is actually a valid result.

Whereas if I want to add a state in my enum the callers _MUST_ update their code due to how Rust works.

The_Colonel2y ago

> otherwise why would you need to know why an operation failed to such detail?

I'm not defining the errors like DBConnectionError or OutOfMemoryError - it's the framework/platform which defines them and throws/returns them.

> But the reality is that the user not being there isn't exceptional.

Which is the same as exception. But now you have this visual noise of something you claim you don't care about. An unchecked exception makes this irrelevant noise go away.

    try {
        ...
    }
    catch (UserNotFoundException e) {
        // handle ...
    }

I'm catching exactly the exception I want. Where I'm catching too much? Where do I need to take it apart?

(This particular example of exception usage is bad, though, as it smells of exception control flow. Here using Maybe type would be better)

> Whereas if I want to add a state in my enum the callers _MUST_ update their code due to how Rust works.

Which is good for some cases where the enum describes "business" cases.

1 more reply

arcbyte2y ago

smallerfish2y ago

Or Kotlin's approach:

   fun getUser(userId: UUID): User?

1 more reply

bedobiOP2y ago

WirelessGigabit gets it. That last fact is huge - functional error handling forces callers to handle (or pass on) exactly what can go wrong, no more, no less. (unlike exceptions)

1 more reply

bedobiOP2y ago

j / k navigate · click thread line to collapse