My philosophy of exceptions: they're always ambiguous (2021) • Hacker News Board

Re: My philosophy of exceptions: they're always ambiguous (2021)

#31

Post by wruza » Sun, Jun 30, 2024, 10:03 AM UTC

I’ve been programming for many years and never thought of or met any issues with exceptions. It’s a useful mechanism to stop execution and send a structured signal up the call stack to where you expect it. If you don’t have issues (e.g. data, syntax, performance related) with the way you use exceptions, it’s safe to ignore all philosophical distresses.

What does it actually mean? When should I use it? Is this correct? Is my usage aligned with the idea behind it? These are all questions of a restless mind. The one that stands in front of a toolbox and cannot choose a type of a hammer for a trivial job where even a rock will do.

Re: My philosophy of exceptions: they're always ambiguous (2021)

#32

Post by 7bit » Sun, Jun 30, 2024, 10:41 AM UTC

tsimionescu wrote: post #21

kelnos wrote: post #11

Earlier quoted context omitted.

> An exception is when code can no longer do any meaningful work. That is quite obviously not true, not even on the surface. I have written tons of code where I've caught exceptions and then continued to do meaningful work. The author's Python example even contradicts your statement. Sure, maybe they should validate the URL first. But even if they did that, the server could be down, the user's internet could be down,…

The code that catches an exception can continue, but the point was about the code that threw the exception. You throw an exception if you can't continue the work you're currently doing, for whatever reason. Of course, the rest of the program can very well continue: some other part will catch the exception you threw and decide what to do next. Ending the entire process is an extreme case, that should be reserved for o…

> Also, there is little fundamentally different between throwing an exception and returning an error result.

Thank you. I was about to reply the same. The most notable difference is that from a usage-perspective is that exceptions bubble up automatically, whereas errors must be returned manually.

I usually don't follow the error vs. exception debate because both have their difficulties and both let's you write code that behaves different than you anticipate.

I prefer exceptions, especially how Python handles them (most of them at least). The only thing I really would love to see is something like Rusts Option() type in Python so assigning values to variables inside a try: would not require me to have variables with typ int|None. That's really yuck.

Re: My philosophy of exceptions: they're always ambiguous (2021)

#33

Post by 7bit » Sun, Jun 30, 2024, 10:49 AM UTC

Mikhail_Edoshin wrote: post #29

xg15 wrote: post #25

You can have the same philosophical distinction over the term "error". Is it really an error if your computer did not literally catch fire or otherwise took physical damage? And yet this hasn't stopped even nontechnical people from using the term without any significant communication problems. I think a more interesting discussion might be what exactly the difference between "errors" and "exceptions" is in computing,…

There was a book “C Interfaces and Implementations” by David R. Hanson and he put it so: there are user errors (input/data errors), program bugs (things we 'assert') and everything else are exceptions. So a non-existent file is a user error, uninitialized memory is a program bug, and an arithmetic overflow is an exception. Not sure if this is useful. I myself think errors and exceptions are misleading terms. There is…

> There was a book “C Interfaces and Implementations” by David R. Hanson and he put it so: there are user errors (input/data errors), program bugs (things we 'assert') and everything else are exceptions. So a non-existent file is a user error, uninitialized memory is a program bug, and an arithmetic overflow is an exception.

I don't agree with this definition in the same way I don't agree with many others not found in books.

These definitions always reflect the personal view of their authors, but are fundamentally just an interpretation of their own thoughts. There is nothing objective about it. It's just a philosophical or semantic debate.

For example, why is uninitialized memory a bug, but an arithmetic overflow is not? In both cases it would have been the developers responsibility to initialize the memory and prevent an arithmetic operation that overflows.

Re: My philosophy of exceptions: they're always ambiguous (2021)

#34

Post by TheTrueScotsman » Sun, Jun 30, 2024, 1:35 PM UTC

[flagged]

Re: My philosophy of exceptions: they're always ambiguous (2021)

#35

Post by Mikhail_Edoshin » Sun, Jun 30, 2024, 1:43 PM UTC

7bit wrote: post #33

Mikhail_Edoshin wrote: post #29

Earlier quoted context omitted.

There was a book “C Interfaces and Implementations” by David R. Hanson and he put it so: there are user errors (input/data errors), program bugs (things we 'assert') and everything else are exceptions. So a non-existent file is a user error, uninitialized memory is a program bug, and an arithmetic overflow is an exception. Not sure if this is useful. I myself think errors and exceptions are misleading terms. There is…

> There was a book “C Interfaces and Implementations” by David R. Hanson and he put it so: there are user errors (input/data errors), program bugs (things we 'assert') and everything else are exceptions. So a non-existent file is a user error, uninitialized memory is a program bug, and an arithmetic overflow is an exception. I don't agree with this definition in the same way I don't agree with many others not found i…

In his interpretation exceptions were just a little short of being fatal errors. They were almost fatal errors but with an optional escape hatch. But I agree all these distinctions are vague and do not seem to be fundamental differences.

Exceptions are a side effect of nice syntax. When we write

    a = b + c

in a modern language quite a lot can happen behind the scenes. Yet the form implies 'a' will always be a sum of 'b' and 'c' whatever this means. There is no notion of 'a' not being a sum. So it seems there are two ways: either we provide a separate error handling mechanism (exceptions) that stops the execution and leaves 'a' undefined or we somehow turn 'a' into either a sum of 'b' and 'c' or an error (sum types).

Re: My philosophy of exceptions: they're always ambiguous (2021)

#36

Post by Mathnerd314 » Sun, Jun 30, 2024, 2:18 PM UTC

xg15 wrote: post #25

You can have the same philosophical distinction over the term "error". Is it really an error if your computer did not literally catch fire or otherwise took physical damage? And yet this hasn't stopped even nontechnical people from using the term without any significant communication problems. I think a more interesting discussion might be what exactly the difference between "errors" and "exceptions" is in computing,…

Errors have the connotation that something has gone wrong, exceptions do not. Exceptions as used in CS also do not have the connotation that they are unusual, as pointed out by the article. But generally, every error can be made into an exception.

As far as deciding on what they mean, I have brought up ChatGPT's definitions in arguments and been laughed at. People seem more interested in arguing than in making their vocabulary precise.

Re: My philosophy of exceptions: they're always ambiguous (2021)

#37

Post by LtWorf » Sun, Jun 30, 2024, 3:26 PM UTC

lloeki wrote: post #16

> Python, C++, Ruby and Java all use exceptions. To them, “exception” means, “nifty piece of syntax kinda like goto.” Not Ruby. In idiomatic Ruby^ exceptions are for exceptional cases, not code flow. "nifty piece of syntax kinda like goto." is the much underused but very powerful catch+throw. Or rather, it's a stack unwinding mechanism: think baseball, the catcher expects a ball, with the ball being a message to be p…

[1]: isinstance(StopIteration, Exception)

[1]: False

Re: My philosophy of exceptions: they're always ambiguous (2021)

#38

Post by winstonewert » Sun, Jun 30, 2024, 3:33 PM UTC

erik_seaberg wrote: post #8

wvenable wrote: post #4

Earlier quoted context omitted.

In .NET, they have 2 sets of parsing functions, "Parse" and "TryParse" for parsing strings into other types. The first throws an exception if it can't parse and the second returns a Boolean indicating success or failure. Which function of these you use as a programmer is dependent on the context and it indicates your expectation. You might use "Parse" if you reading a well-defined file format where the string will al…

Was this a workaround for frequent exception handling being too expensive on some platform? I like how Java lets some exception instances be reused without stack frames, so performance issues are less likely to compromise API design.

I think the causation runs in the opposite direction. These exceptions for these platforms were implemented in an inefficient fashion BECAUSE they thought that exceptions should almost never be thrown.

Re: My philosophy of exceptions: they're always ambiguous (2021)

#39

Post by rerdavies » Sun, Jun 30, 2024, 3:54 PM UTC

kelnos wrote: post #11

wvenable wrote: post #2

> So you think you know what an “exception” means? An exception is when code can no longer do any meaningful work. This could be because of a programming bug, unexpected input, network issue, hardware issue, etc. The cause doesn't really matter. What matters is that there is no way forward for the code. And this is a decision that is made (or not made) by the programmer. In this author's Python example, he chooses ac…

> An exception is when code can no longer do any meaningful work. That is quite obviously not true, not even on the surface. I have written tons of code where I've caught exceptions and then continued to do meaningful work. The author's Python example even contradicts your statement. Sure, maybe they should validate the URL first. But even if they did that, the server could be down, the user's internet could be down,…

abort() isn't really an option for broad classes of applications (UI applications, services, web servers &c).

Re: My philosophy of exceptions: they're always ambiguous (2021)

#40

Post by wvenable » Sun, Jun 30, 2024, 5:51 PM UTC

taberiand wrote: post #28

kaba0 wrote: post #18

I think this topic has been discussed countless times, and this post fails to add anything worthy to it. My two cents: use result types, or their analog in your language for expected error conditions, and use exceptions for exceptional situations. Example for the former is parsing, which has an expected failure mode - something couldn’t be parsed as intended. Example for the latter is a network issue during an API ca…

The main problem I have with exceptions is that libraries can't be trusted to only throw exceptions in exceptional situations, or even properly document the situations in which they throw exceptions, so my code must be constantly paranoid about every call into library code. Contrast this with languages that provide result types and the certainty of either handling or passing up the error, particularly when the langua…

I just assume every piece of code can throw any kind of exception. If some code doesn't throw an exception today, it might change tomorrow. It ultimately doesn't matter. There is no need to worry about it.

There are only key points in any application where you can properly handle errors/exceptions and only certain errors/exceptions that can be handled in a specific way. Neither the location of the handler or can be handled has anything to do with what code triggered the error.

Explicitly declaring exceptions/errors completely breaks polymorphism. The library that you call exposes it's internals that way and if those internals change then your code breaks. Either that, or to maintain a consistent API, the library has to lie about the errors it produces by hiding the real error away in a more generic error type.