Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

You’re better off using Exceptions

eiriktsarpalis.wordpress.com

Post reply on HN
Print view View original

101–110 of 242 posts

Re: You’re better off using Exceptions

#101

Post by wizzwizz4 »

shepmaster wrote: post #56
ferzul wrote: post #46

Earlier quoted context omitted.

If Rust devs took an everyday English word and gave it a different meaning, isn't it their fault when they have to train everyone into discarding their intuitions? It sounds like it means “code that is unsafe for a particular reason”; name the reason and leave developers capable of criticising code that is unsafe for other reasons, too. Unchecked Exception throwing code and stringly typed code are both unsafe. The wo…

> If Rust devs took an everyday English word and gave it a different meaning Perhaps, but if we had come up with a new word, you or someone else would complain that we had done that instead of using a word that people already "understood". :-) English is a language full of elision, and there's nothing inherently wrong with using one word for closely related meanings. When being precise, Rust uses the term "memory uns…

We call it panicking because there's no assumption that you're always able to catch panics. Panicking is an AAAH EVERYTHING WENT WRONG kind of thing, which might trigger an immediate abort if the program is compiled in super-ultra-speedy-make-debugging-really-hard mode; if your code panics, it's always the programmer's fault.

The language provides a way of kinda-sorta recovering from an everything-goes-wrong situation only to be nice to you, and not because that's a thing that's generally possible. You can't always recover from a segfault, or a buffer overrun, or the rest of the kind of things that cause panicking, even if you know that they're theoretically possible in advance, because if you could you would've fixed them already. The best you can do is make your web server return a 500, send logs, ditch its cache, restart in a sane state and hope for the best. You're not recovering that half-finished task, because the programmer can't reason about the program state in a situation where their code has been shown to be wrong.

Panics are only for exceptional failure cases. If this confuses people, it's (probably) because they only thought they understood; they needed confusing.

Re: You’re better off using Exceptions

#102

Post by UK-Al05 »

ProstetnicJeltz wrote: post #75
ravenstine wrote: post #14

My problem with exceptions isn't so much exceptions themselves but the way they're used. The way I see it, exceptions should only be used for things that are irreconcilable, which most of the time is interpreter errors(e.g. undefined is not a function). In other words, I don't think it's that common that custom exceptions are needed outside of assertions to prevent the developer from doing something stupid. If you ar…

We tried to use a result type in C# for cases like this. For example, we want to save an object, returning the updated object (on success), or an error on failure. Unfortunately in static languages this leads to an unholy amount of boilerplate: public Result PerformUpdate(int goodThingId, UpdateForm form) { ... return new Result (error); ... return new Result (obj); } The type annotations were hell. Sometimes there w…

Frankly, that's because C# doesn't support proper discriminated unions in a concise way.

F# is a lot better at using result types. You don't even need to specify the return type.

Re: You’re better off using Exceptions

#103

Post by sombremesa »

ravenstine wrote: post #87
Seenso wrote: post #62

Earlier quoted context omitted.

> A record not being found is a normal thing! It's not a normal thing for code that needs that record that wasn't found. > They literally tell you nothing and there's no way to solve them without catching/rescuing them. A null value, a plain "error" object, or an error argument in a callback would have been sufficient. If I need an exception to be raised for this kind of thing, I'll do it myself. They tell you lots:…

> It's not a normal thing for code that needs that record that wasn't found. No offense, but I don't know where that idea comes from. Systems are checking for records all the time in ways where the absence of data doesn't necessitate throwing an exception. For instance, a page, user, or piece of media on a website may have existed at one point but was since deleted, but still has a permalink floating around the net.…

Many years of experience tell me that you're going down the futile path of getting a tiger to change its stripes. As more and more devs get minted, prepare for codebases (and libraries) to get a LOT more gnarly. Even so, it's a good thing to lower barriers of entry and we can be discerning about where we get our code.

Re: You’re better off using Exceptions

#105

Post by Rusky »

ravenstine wrote: post #71
seanmcdirmid wrote: post #51

Earlier quoted context omitted.

If you expected the record to be found, the failure of finding it is an exception. If it was an open question, then it isn’t. This is why API generally have checks that allow developers to avoid that failure if the failure is expected (eg Record.exists). What you are suggesting is simply a reverse order (check after vs check before). I think check before leads to a much cleaner API than one that dumps a null or failu…

I don't agree. There is nothing inherently irreconcilable about a record not existing. Anyone who expects a database to always have records and that the absence of a record is an "exception" has a very strange way of thinking. It's like if a car was programmed not to start and to turn on an obnoxious alarm bell because the windshield wiper fluid is empty, and the technicians built in a jumper wire to short that circu…

> Anyone who expects a database to always have records and that the absence of a record is an "exception" has a very strange way of thinking.

This isn't something you can make universal statements about, because it depends on context.

If the program knows it just put or saw the record there, is it strange to assume it's still there? If the program completely controls the database and something else in it implies the record is there, is it still strange to assume?

Sometimes broken assumptions can only signify that something has gone very wrong, and it's not worth handling them at a fine-grained level. That leads to the "gotta catch em all" antipattern the article mentions.

Re: You’re better off using Exceptions

#106

Post by lllr_finger »

chrisseaton wrote: post #26
ComputerGuru wrote: post #20

Earlier quoted context omitted.

Most concise: absolutely. Most performant: never. Most understandable: yes, but only if you are cognizant of which call paths can result in an exception and which can’t (i.e. until your code base becomes too large or you’re not the one that wrote it).

> Most performant: never. I disagree. An exception can be faster than manually unwinding a set of nested scopes.

Most exceptions, at least in the JVM where this is commonly debated, will incur a penalty of building up the exception and unwinding the call stack. What aspect of performance are you using as an example?

Re: You’re better off using Exceptions

#107

Post by iainmerrick »

Seenso wrote: post #62
ravenstine wrote: post #14

My problem with exceptions isn't so much exceptions themselves but the way they're used. The way I see it, exceptions should only be used for things that are irreconcilable, which most of the time is interpreter errors(e.g. undefined is not a function). In other words, I don't think it's that common that custom exceptions are needed outside of assertions to prevent the developer from doing something stupid. If you ar…

> A record not being found is a normal thing! It's not a normal thing for code that needs that record that wasn't found. > They literally tell you nothing and there's no way to solve them without catching/rescuing them. A null value, a plain "error" object, or an error argument in a callback would have been sufficient. If I need an exception to be raised for this kind of thing, I'll do it myself. They tell you lots:…

>> A record not being found is a normal thing!

> It's not a normal thing for code that needs that record that wasn't found.

This is something of a religious dispute and there are arguments both ways.

But I think it’s important to note that an exception is vastly more expensive than a simple function call or return value. So I’d say you need a really good reason to use exceptions.

I agree with the GP that in general, “lookup failed” is not an exceptional error. If it always succeeds, why are you looking up something in the first place?

I agree with the original poster that exceptions do have their place, even though they’re expensive.

If you have the primary key of a database object that you know to be correct, and you try to retrieve that record but fail, that might legitimately be an exception (unless having records deleted from under you is a common occurrence in your app).

Re: You’re better off using Exceptions

#108

Post by Gepsens »

So much confusion between Exceptions and Errors in this thread. Exception abuse is for bad code that needs to return early, because they have no pattern matching, like Java and JavaScript. Nice languages have error handling, think Go, Elixir, Rust, Scala.

Re: You’re better off using Exceptions

#109

Post by kenoyer130 »

Seenso wrote: post #62
ravenstine wrote: post #14

My problem with exceptions isn't so much exceptions themselves but the way they're used. The way I see it, exceptions should only be used for things that are irreconcilable, which most of the time is interpreter errors(e.g. undefined is not a function). In other words, I don't think it's that common that custom exceptions are needed outside of assertions to prevent the developer from doing something stupid. If you ar…

> A record not being found is a normal thing! It's not a normal thing for code that needs that record that wasn't found. > They literally tell you nothing and there's no way to solve them without catching/rescuing them. A null value, a plain "error" object, or an error argument in a callback would have been sufficient. If I need an exception to be raised for this kind of thing, I'll do it myself. They tell you lots:…

In Java/C# land exceptions are EXPENSIVE. Like magnatudes more expensive. You have to build a full stack trace etc. Removing places in the code where it is "Throwing exceptions for non exceptional circumstances" has a dramatic performance increase benefit.

Re: You’re better off using Exceptions

#110

Post by hombre_fatal »

ravenstine wrote: post #87
Seenso wrote: post #62

Earlier quoted context omitted.

> A record not being found is a normal thing! It's not a normal thing for code that needs that record that wasn't found. > They literally tell you nothing and there's no way to solve them without catching/rescuing them. A null value, a plain "error" object, or an error argument in a callback would have been sufficient. If I need an exception to be raised for this kind of thing, I'll do it myself. They tell you lots:…

> It's not a normal thing for code that needs that record that wasn't found. No offense, but I don't know where that idea comes from. Systems are checking for records all the time in ways where the absence of data doesn't necessitate throwing an exception. For instance, a page, user, or piece of media on a website may have existed at one point but was since deleted, but still has a permalink floating around the net.…

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.

    item = db.findItem(id)
    assert(NotFoundError, item != null)
    render('show-item', item)
upstream middleware:

    try {
      res = await downstream() 
    } catch(e) {
      if (e is NotFoundError)
        render('not-found')
      else
        render('internal-error')
    }
you can do this with other patterns for upstreaming errors like Result + Rust's handy short-circuiting, but your example doesn't demonstrate much. what about internal errors like your store throwing a database error, your first example doesn't even have a store capable of erroring? your comparison incomplete. and surely you don't do all error checking at every callsite no matter which pattern you use.
Post reply on HN