Hacker News Reader

Comment by shrimpx | Hacker News Reader

The problem is that in many practical situations you don’t know which situation is “exceptional”.

If you write a jpeg-processing service, it’s intuitive to raise an exception on a malformed jpeg, but there’s no guarantee that only 1% of the jpegs users upload to the service are malformed.

In other words, we treat exceptions as exceptions from our code expects, not what’s statistically unlikely in the input space, which is in many cases impossible to predict with accuracy. (E.g., even if only 1% of your inputs are malformed over all time, on some Thursday you may be hit with 80% bad inputs, making the performance drop across the service unacceptable.)

View on HN

> If you write a jpeg-processing service, it’s intuitive to raise an exception on a malformed jpeg (..)

Not really. Having to parse a malformed doc is not an exceptional situation: it's a basic use case, and one which is very close to the happy path.

And it's one for which exceptions are a perfect fit. Even if at the entry point of your "parseJpeg()" function you instead return a variant<result, error>, internally propagating that error via exceptions is the "correct" design. Otherwise you're littering the code with branches, which makes the expected common path slower.

Which the paper covers, that's the std::expected section: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p254...

As a bonus not only is using exceptions for this faster, it's also less error prone. There's much less risk of any intermediate function or helper abstraction failing to propagate an error code properly.

Well, it would be if exceptions weren't avoided like the plague in C++ because they have a, well, bad implementation, which can't be meaningfully fixed without ABI breakges (as the paper covers)

If your service is public facing and therefore subject to DoS attacks, you should design around the error path being fast.

Which really should be possible with exceptions. It's a shame that it isn't.

Your opinion being that you should not use exceptions in that type of case. In which cases should you use exceptions?

My experience in using exceptions (and restartable conditions) over the last 40 years is that exceptions are for things you don't have the ability or "knowledge" (i.e. state) to handle locally.

So a function that ingests a file and processes it may throw an exception if the file isn't found so that the UI can catch it and ask the user for an alternative filename (or to give up and not open a file at all).

If you're connecting to a remote machine and don't get a response, you might throw an exception because you don't know if the user typed the name wrong.

While if you are already talking to a machine and it stops responding it's reasonable to wait a moment and retry, as if could be a transient network brown-out which is something you can deal with on your own.

When something happens that violates your assumptions about your own program's behavior, throwing it into a state where it doesn't know what happens next. Kind of like a panic.

This would mean that attempting to open a file that doesn't exist shouldn't throw an exception. But that is exactly what it does in the standard libraries of many languages with exceptions.

It should be up to the application to throw or not, not a library. I write a system service. If it can't find the configuration file, it can't continue, so it throws an exception. If it can't open a file that contains state from a previous run (maybe because it's the first time it's running) that's fine, the program can run without it and thus, no exception.

Not in C++ I believe ?

https://en.cppreference.com/w/cpp/io/basic_ios/exceptions

That is manually throwing an exception if the file doesn't exist.

C++ stdlib does not throw an exception if a file does not exist. I agree with this philosophy because files not existing isn't an exceptional case.

Damn, in all those years I've absolutely never come across this, thanks

The C++ standard IO library doesn't enable exceptions by default, but IIRC that's just a relic of the fact that it dates back to when C++ didn't have exceptions.

It's library dependent. iostreams (part of C++ std lib) doesn't throw exceptions by default but I believe it can be configured to throw if you want.

So, CPU exceptions such as a "page not present" TLB fault should not be used to implement virtual memory.

A "page not present" fault is actually a great example of a resumable condition, which is not quite the same as an exception in the C++ sense.

This is a bit of a stretch. The purpose of the service has to be processing jpegs where they are expected to be bad. Moreover, they have to be mostly bad; i.e. the service is specifically intended for finding rare good jpegs in a deluge of bad ones, as quickly as possible.

In a situtaion where are more bad jpegs than good ones, we still don't necessarily care that they cause the slow path, if the purpose of the service is doing meaningful processing with good jpegs.

Reply on news.ycombinator.com