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

21–30 of 242 posts

Re: You’re better off using Exceptions

#21

Post by vnorilo »

chrisseaton wrote: post #5
reffaelwallen wrote: post #2

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

I also use exceptions for control-flow and I feel no shame about it. It's often the best (most concise, most performant, most understandable) solution to a problem, in my eyes.

You are probably looking for continuations. For many languages exceptions are the nearest approximation.

Personally I have no problem with your approach on the semantic level, but most compiler/interpreter developers consider all exceptional paths as cold as it gets: performance can be "interesting" if you take a lot of them.

Re: You’re better off using Exceptions

#22

Post by foolfoolz »

I’ve pushed for Either[L,R] based coding without exceptions for a while and met a lot of criticism along the way. I still think it has value over exceptions but this post does bring up good points. The one about throwing the stacktrace away is annoying, but with Future your stacktrace is useless anyway. We have a system where every error has a unique id that looks like a jira ticket number so you can find the source very quickly and avoid the stringly typed error.

This section of code is what i want to avoid:

    user = service.getUser()
    bill = billingService.getBill(user)
    notificationService.message(user)
we use the same http client in all underlying service clients. let’s say you get to the end of this block and it results in SocketTimeoutException. How do you know what call did this? you would have to add to every line:

    .recoverWith({case t => new Exception(“billing exception”, t})
to propagate the context up. Either forces you to handle that well and write the context.

a lot of it comes down to style choice because you could do it with exceptions, but i think this makes it easier not forget cases because the compiler will tell you

Re: You’re better off using Exceptions

#23

Post by mceachen »

shadowgovt wrote: post #9
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.

Agreed. I nowadays consider code that might throw any type of exception to be inherently unsafe code; if you don't know what can go wrong, how do you have any idea whether you've addressed all reasonable failure modes?

It depends on the problem domain.

If you've got very tightly controlled inputs, it's not unreasonable to expect tightly-bound results (like the last example in the article).

If you're writing intermediary code between unsafe inputs and other libraries, there might be a reasonable boundary to catch all unknown errors and wrap as a failure.

In PhotoStructure's case, it's an easy solution: I simply don't import the given file. There may be a similar reasonable boundary in your problem space.

Re: You’re better off using Exceptions

#24

Post by bibyte »

shadowgovt wrote: post #15
bibyte wrote: post #6

Earlier quoted context omitted.

Can you please elaborate on those problems ? Personally I believe exceptions are the worst way to handle errors, except for all other ways.

Python's soft static type rules and extremely flexible variable instantiation unfortunately turns every line of code into a potential runtime error, because the code can't know at compile time if a variable was introduced to the global context that could bind to any given name. Typos are therefore deadly at runtime in Python in a way that they fundamentally aren't in other languages; if you try to write foo = 0 if fo…

Maybe I am missing something but I think every dynamic typing system has this problem. I can't see what this has to do with Python and exceptions in general. It is not like there aren't statically typed languages with exceptions. This comment is an excellent critique of dynamic typed systems but it has nothing to do with exceptions.

Re: You’re better off using Exceptions

#25

Post by ferzul »

Exceptions in Haskell are unavoidable and awful. If you want to write code that responds to the errors that could occur, even some of them, you basically have to read the library source because they're completely undocumented in many libraries - even in the standard library (try something exotic like, um, reading a file). And that means you need to know your whole stack.

If they were at least declared in the type so the compiler could give me a warning.

Re: You’re better off using Exceptions

#26

Post by chrisseaton »

ComputerGuru wrote: post #20
chrisseaton wrote: post #5

Earlier quoted context omitted.

I also use exceptions for control-flow and I feel no shame about it. It's often the best (most concise, most performant, most understandable) solution to a problem, in my eyes.

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.

Re: You’re better off using Exceptions

#27

Post by shepmaster »

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.

> so that I can do things like internationalization

Can you expand a bit on how you do this internationalization? I've got a low-priority issue [1] to investigate how to integrate SNAFU and Fluent to get i18n for error messages, but knowing how someone does it today would be super helpful!

[1]: https://github.com/projectfluent/fluent-rs/issues/107

Re: You’re better off using Exceptions

#28

Post by lern_too_spel »

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.

Exceptions are typed in most staticly typed languages as well.

Re: You’re better off using Exceptions

#29

Post by baby »

I’d say this works in Erlang because it is part of the culture, but in java or python what I’ve seen mostly is people forgetting to catch exceptions, or not being able to pinpoint where exceptions are catched.

Re: You’re better off using Exceptions

#30

Post by LOL_Arch_Linux »

While my favorite language (Erlang) has Exceptions, I really like the "let it crash" model -- let the whole light-weight thread die and have the controlling thread (a/k/a "supervisor") figure out what to do.

I've seen insane Java programs where tracking how many layers up Exceptions are caught was mind-twisting. And conversely, when everything was wrapped in a try/catch and then, essentially ignored.

Post reply on HN