Hacker News Reader

Comment by fivea | Hacker News Reader

> 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.

View on HN

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?

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.

Not in C++ I believe ?

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.

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

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

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.

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.

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.

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.

Reply on news.ycombinator.com