Hacker News Reader

Comment by dscrd | Hacker News Reader

Exceptions are a bad idea. Even in the more saner languages such as python, they tend to obfuscate needlessly.

so you prefer to decentralize your exception handling code ? how do you scale that ?

The problem is that when exceptions are available, people will start using them for non-exceptional things and (the worst case) basic control flow.

Case in point from a popular framework, Django: the standard way of getting an object from the DB via the ORM is Class.objects.get. This method either returns a single object or raises on exception if there are zero rows in the db or another exception if there are two or more rows. It may also raise other kinds of exceptions.

Now, it's clear that having zero rows is not very exceptional, and even >1 is somewhat debatable. Note especially that this is not just some weekend project by a nobody, it is a framework that is widely used and respected.

>> and (the worst case) basic control flow. I call it "java-way goto"

I can't agree about Class.objects.get - method must return exactly one row by known pk value.

So it perfectly sane to raise exception for zero rows.

Class.objects.filter is working the way you want.

Except that get accepts as parameters non-unique non-primary fields too.

I have every reason to believe that the Django devs are capable people who thought about this and landed on this specific usage with a clear rationale... but it still is a misuse of error handling capabilities of a language. And a sort of misuse that everyone else does sometimes as well.

I agree with your first paragraph but not with the Django example. User.objects.get(id=1) failing is exceptional because you are asking for an object with a specific and unique property. Otherwise, you would be using User.objects.filter(age>20) (which doesn't throw an exception).

I might kinda agree that exact queries against primary keys not having results (or having more than 1) would be exceptional, but this actually happens for every other field as well.

that's not a Django problem; it's a Python problem. Using exceptions for control flow is idiomatic in Python. Case in point: a generator is supposed to raise a StopIteration exception in order to signal termination.

Sometimes you want non-local transfers of control, beyond just exceptions. Python uses exceptions as both error conditions and signals.

It's seemingly nearly mandatory in discussions regarding exceptions to bring up Common Lisps's condition system, which is a superset of exceptions. I've included a link to a chapter from a book on Lisp.

http://www.gigamonkeys.com/book/beyond-exception-handling-co...

Go has no exceptions. Instead, functions can return multiple values, one of which is an error, and you check the error value on invocation. It's tedious and awful and makes your code very ugly and it's absolutely correct and I love it. It takes some getting used to, but once you do it for a while, you realize that exception handling systems are broken and unnecessary. E.g.:

    func MaybeAnInt() (int, error) {
        if FAIL {
            return 0, errors.New("this is the error message")
        }
        return 42, nil
    }

    x, err := MaybeAnInt()
    if err != nil {
        // handle your error
    }
    // normal shit here.

That is the best argument against GO I have ever seen.

You now have to mix up your exception code and your normal code (or, as I suspect most people will do, ignore the error return value).

Did they kill stack traces too?

You cannot ignore the error return value in Go.

If you would think a bit more broadly, you might also see this so that all the error handling code is visible, explicit and right there with the actual logic, and not hidden away what might be (and often is) multiple layers of modules.

>You cannot ignore the error return value in Go.

that's not true. You can ignore the second parameter by explicitly naming it with an underscore, like this:

    x, _ := MightFail()

Well ok, you can explicitly ignore them, but not by being negligent.

it sounds bad in theory, but in practice it turns out to be quite good. It's actually the opposite; because you know that there's no exceptions, control flow is very obvious. Whether a function does or does not return an error is a part of its signature. You always know, when calling a function, if it may or may not return an error, and it is up to the caller to decide what to do with that error. As a result, there's no control flow pitfalls like forgetting to close a filehandle because an exception was thrown in some function that you didn't know could throw an exception.

>Did they kill stack traces too?

no, we have stack traces.

Also, it's Go, not GO.

that does not scale. you can have hundreds of calls that require error handling inside your code. considering your example you would get the section "//handle you error" hundreds of times. sprinkled all over the place.

Reply on news.ycombinator.com