Hacker News Reader

Comment by psychoslave | Hacker News Reader

At this point you might also consider a `try: treat(x); catch unauthorized: fallbackly_treat(x)` pattern.

Disagree. Someone attempting to do something while unauthorized is oftentimes not an exceptional state and regular business logic depending on how access is given to different endpoints. Do not use exceptions, which are "heavy" (capturing call-stack etcetera), for something that commonly occurs.

Using an exception for authorization failures avoids TOCTOU security holes. Also, in many cases, there are intermediate layers of the call stack that don't have any useful contribution to failure handling; the best they can do is forward the failure return value up the stack. And if one part of an operation fails because of a lack of permissions, it is usually dangerous to continue processing without handling the failure, which is the default behavior that failure return values have in most languages.

By contrast, the performance cost of capturing stack traces when there's an authorization error is insignificant. How many authorization errors do you have per second in normal operation? For many systems, the answer is down in the millibecquerels to microbecquerels.

Under these circumstances, the balance leans quite heavily to the side of using exceptions to report authorization failures.

This is interesting and compelling. I wonder about spambots though, when authorizing a service exposed to the web. Doesn't it get expensive pretty quickly when a bot decides to scan the site and floods it with requests that all exception?

Efficient handling of authorization failures is neither necessary nor sufficient to preventing such denials of service.

Put another way: exceptions are exceptions to the normal program flow. They should not be used to communicate expected errors. I think of them as analogous to the `if (do() != 0) { goto out; }` paradigm of C.

Unless you're using Python where exceptions occur every time you finish looping. https://docs.python.org/3.7/library/exceptions.html#StopIter...

True. However, it is unusual for the user to deal with StopIteration themselves (therefore somewhat exceptional).

> Put another way: exceptions are exceptions to the normal program flow.

There's no iron law or mathematical proof that says this is optimal. It's just a preference some people have. Exceptions are the error handling mechanism for many programming languages. Authorization errors are a type of error. Under this construction, exceptions are the appropriate way to handle authorization errors, including when a principal attempts to access an resource they are not authorized to access.

In my experience, this isn't always true. Exceptions are great in the context of web requests. If anything goes wrong, we have defined consistent behavior (re: http 404). It's so effective, there's a whole host of checked exception codes.

Reply on news.ycombinator.com