You’re better off using Exceptions • Hacker News Board

Re: You’re better off using Exceptions

#31

Post by shadowgovt » Mon, Feb 03, 2020, 4:41 PM UTC

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…

I find the mindset that exceptions are the right way to handle ordinary scenarios symptomatic of what I call "happy path coding:" assuming that the stars are always perfectly aligned for your program to work, and nothing ever goes wrong, and if it does it's someone else's problem.

It's a fine approach for prototyping but we should be highly suspicious of it for code people rely upon to work. As complexity approaches infinity, the odds of the system being "happy path"-aligned approach zero.

Network-relevant programming (such as web UIs), in particular, really highlights this fact (since any given network request is always allowed to fail, and "user closes their laptop or mobile device, moves somewhere else, and resumes work on an entirely different physical network" has gone from a rare occurrence to an extremely common one in the past two decades).

Re: You’re better off using Exceptions

#32

Post by smegma2 » Mon, Feb 03, 2020, 4:42 PM UTC

Can't the rethrowing logic be expressed using `fmap`?

    λ :set -XTypeApplications 
    λ :t fmap @ (Either Error)
    fmap @ (Either Error) :: (a -> b) -> Either Error a -> Either Error b

Re: You’re better off using Exceptions

#33

Post by BiteCode_dev » Mon, Feb 03, 2020, 4:43 PM UTC

I don't think it should be "exception vs returned value".

First, if you are using a dynamic language, then exceptions make sense. You want to get there quickly, not handle every corner cases.

At the opposite spectrum, if you are writing rust, of course you want something very explicit and extremely aggressive to deal with errors.

They just serve different needs.

Also, exceptions don't have to be implicit, difficulties arise when the code you are using do not or cannot declare what can of exception can happen when you call it.

But if the language let you declare all the stuff you can raise, then there is not much difference.

Re: You’re better off using Exceptions

#34

Post by shadowgovt » Mon, Feb 03, 2020, 4:43 PM UTC

mceachen wrote: post #23

shadowgovt wrote: post #9

Earlier quoted context omitted.

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 give…

Agreed. And sometimes, the right solution is to assume inherently unsafe code and do one's best to guarantee safe behavior anyway. Operating systems and web browser tab isolation, for example, operate under this principle (as do many web servers that use multithreading to support multiple requests in the same process, so that one bad request doesn't deny service to N hundred completely unrelated user sessions).

... but if one is doing that, one should do it very explicitly. I prefer a codebase that separates regular flow of operation from the "catch-all" or "panic-recover" loops that indicate "The buck stops here for catastrophic failure."

Re: You’re better off using Exceptions

#35

Post by sethammons » Mon, Feb 03, 2020, 4:43 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

Having worked in Twisted's framework, I utterly despise exceptions as control flow. One service I work in is 140k lines of Twisted python (aptly named). I can't wait for us to finally kill it and never deal with Twisted again.

Re: You’re better off using Exceptions

#36

Post by baby » Mon, Feb 03, 2020, 4:44 PM UTC

shadowgovt wrote: post #8

eirik's making some very good points regarding the downsides to avoiding exceptions (particularly in the notion that one loses stack trace details and if one doesn't think about how debugging will be done without them, one is in for a world of hurt). I think I only have some significant disagreement with one observation they've made, which is around runtime errors: "It’s by such misadventure that the working F# progr…

> In other words, a correct program should have no runtime exceptions, and if one happens, it should explode as messily, noisily, and identifiably as allowed

This is not always true. For example if you are writing high assurance software, and the error is recoverable, you really don’t want to crash. You want to catch it, log it, and continue/recover execution.

Of course, now you need to make sure that you’re not catching an exception that is not recoverable.

Re: You’re better off using Exceptions

#37

Post by holtalanm » Mon, Feb 03, 2020, 4:44 PM UTC

i think there is a distinct difference between an exception, and a recoverable error.

Result is not intended to be used for exceptions, but rather recoverable errors. There are a number of situations where I have used Result to recover from an exception that was expected, but it would be folly to try to handle all error paths (especially with runtime errors).

I think the author is trying to convey the point that we shouldn't use Result as a catch-all, but rather as a means of conveying possible known error paths for a function. There will always be the possible unknown error paths, which are handled by the runtime's exception handling/reporting.

Re: You’re better off using Exceptions

#38

Post by dana321 » Mon, Feb 03, 2020, 4:45 PM UTC

What's exception handling actually doing internally?

Genuinely interested and i need to know.

Must be some kind of "goto catch block" internally when you throw an error. It has to stop the execution and jump somewhere, but that somewhere is set in the code where it catches the error.

If you're calling a function then that function throws an error, it has to prematurely exit to somewhere so there must be a stack of the locations of the catch blocks or something? That then unroll as you exit the try/catch blocks as well.

Re: You’re better off using Exceptions

#39

Post by hocuspocus » Mon, Feb 03, 2020, 4:45 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…

> I don't know Rust but it sounds like equivalent to much maligned Java's checked exceptions?

Ergonomics are important. Chaining calls to functions that return a monadic Result/Either type is easier and neater.

Re: You’re better off using Exceptions

#40

Post by shadowgovt » Mon, Feb 03, 2020, 4:45 PM UTC

shepmaster wrote: post #17

shadowgovt wrote: post #9

Earlier quoted context omitted.

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's not clear if you are continuing to refer to Rust as your parent post did, but if so, note that this is not the standard Rust meaning for "unsafe". Using it in such a way makes it more complicated to discuss and explain the Rust-specific meaning.

Thank you for the clarification; I was using 'unsafe' colloquially and not in the Rust sense.