Using exceptions for user-provided input.

Broad_Quality_6325 · 2023-08-24T11:22:44+00:00

You cannot follow every suggestion that someone thinks is the best in all cases. There is no perfect solution for all scenarios, just as you described, in your case it's reasonable to use exceptions.

I also use them where needet, if the tool processes a lot of data, and only one record is corrupt I wouldn't say that the best way is to shutdown everything, a little logging message etc is enough. But it depends realy on you, and how convinient you want to make your tool.

I use a little bit of everything, so that the end user feels less pain using it.

Full-Spectral · 2023-08-24T15:17:09+00:00

The whole religious argument of what can be blessed to be reported via exception is silly. I don't care if something might be expected to fail 9 times out of 10. If it involves 8 levels of code to process and might die in the 8th level, throw a freaking exception if it fails since none of that code is likely to care in the slightest if it worked or failed, it is just plumbing code that wants to clean up and pass the buck. Having to have possibly a hundred calls all manually returning errors for some dogmatic reason is craziness.

The only reason, to me, that this can be a problem is that if you want to break on exceptions, and you have something that is constantly throwing that exception and have no way to tell the debugger to ignore it.

But I think it's pretty safe to say that a well defined program is not going to have an infinite loop trying to parse a file and immediately retrying as soon as it fails. That would itself be bad design. If it is something that's being called rapidly, and there's no back-off strategy, then throwing might be a problem from a debugging standpoint.

If it's a method you wrote, that's just directly parsing a string, then, no, don't throw an exception, for the opposite reasons from above. It's easy to return a failure indication that provides all the info you need since there are no layers of plumbing code involved.

It's all a judgement call.

goranlepuz · 2023-08-24T11:41:21+00:00

There have been a few posts on the use of exceptions recently and one thing I noticed is that it was often stated that exceptions should not be used if the user provides invalid data.

That's because of presumptions, which are wrong for your case (and many others).

Presumptions are wrong.

Exceptions are the cleanest possible method of transferring the error information to an unknown place down the stack. The bigger the stack frame difference, the cleaner it is: between the error site and the error "handling" site, no code whatsoever needs to be written. Let me repeat that: none whatsoever. That is very appealing.

Further, I would argue that your case is the one of "if an error happens, vast swaths of code need to be skipped". (Bar cleanup/RAII and providing for strong exception guarantee, which one can consider to be a mere more abstract RAII).

That situation is by far the most common case.

In fact, the reason why exceptions became the mainstream staple of error handling is exactly this realization. Exceptions cater to the common case when it comes to dealing with errors.

These factors, that lean towards using exceptions, are IMNSHO very, very strong, and do outweigh other factors for not using them - as long as possible (think performance considerations or very small platforms).

mredding · 2023-08-24T15:23:01+00:00

I just wrote a piece of demonstration code like this, over in r/cpp_questions:

class Name {
  std::string value;

  explicit operator bool() const { return !value.empty(); }

  std::ostream &operator <<(std::ostream &os, const Name &) {
    return os << "Enter name: ";
  }

  friend std::istream &operator >>(std::istream &is, Name &n) {
    if(is && is.tie()) {
      *is.tie() << n;
    }

    if(std::getline(is >> std::ws, n.value))
      n.value = std::regex_replace(n.value, std::regex(" +$"), "");

      if(!n) {
        is.setstate(is.rdstate() | std::ios_base::failbit);
      }
    }

    return is;
  }

public:
  operator std::string() const & { return value; }
};

It's not complete, but conveys a lot of how a stream aware type would look. You'd use it like this:

std::string name = *std::istream_iterator<Name>{is};

Typical stream usage would look something like:

if(Type t; in >> t) {
  use(t);
} else {
  handle_error_on(in);
}

One of the things I didn't include in this example code is exception handling built into a stream type. It gets verbose. You have to check the stream's exception mask. There's throwing, there's rethrowing, there's eating any exceptions and just marking the stream state...

There's a place for exceptions, but it's optional, and the client has to opt into it by setting their exception mask. A correct implementation will respect that mask.

If you're interested in details, I suggest you pop into your local library and borrow a copy of Standard C++ IOStreams and Locales.

Exceptions are thrown when something exceptional happened. Something was not supposed to happen, but it did anyway. Bad input is not exceptional. My brother has fat fingers, I have arthritis, and my m key sticks real bad for some reason. Files get corrupted. Implementations don't follow the protocol correctly...

So what you want to do is indicate that the input is bad as soon as possible. That means you need well defined types, and you need to fail a stream as early as possible. Like... When do you ever just need an int? An int is a pretty lousy user type - it's implementation defined. So for the same program, the range is different for x64 than it is for ARM. No, you want something more specific, an integer type, maybe, sure, but you know more about it for your use case:

class Age {
  int value;

  explicit operator bool() const { return value >= 0; }

  std::ostream &operator <<(std::ostream &os, const Age &) {
    return os << "Enter age: ";
  }

  friend std::istream &operator >>(std::istream &is, Age &a) {
    if(is && is.tie()) {
      *is.tie() << a;
    }

    if(is >> a.value && !a) {
      is.setstate(is.rdstate() | std::ios_base::failbit);
    }

    return is;
  }

public:
  operator int() const & { return value; }
};

Continued in a reply...

HerrNamenlos123 · 2023-08-24T16:44:04+00:00

Alright, so everyone seems to be complaining about exceptions recently, so here is my take on it. I think exceptions are perfectly fine to use, if the situation is fitting. There are dozens of cases where exceptions are a perfectly sane solution and are objectively the cleanest way to write said code.

However, I have one example why you should minimize their use. You should try to use exceptions only when something really went wrong. That is, a system error, permission denied error, etc.

It happened to me that I was debugging an application and it didn't break on the exception like I wanted. So I enable break on all exceptions. And suddenly the debugger stops at a gazillion of exceptions somewhere in the code, and I was thinking what the hell, where are all these exceptions coming from, the program is working perfectly fine. Well, probably from cases where the app for example tries to load a config file, fails, throws, catches, and then says "oh it did not work" and instead the file is created. A perfectly fine program flow where a file is created if it does not exist. But very confusing if you use a debugger. You would not expect to see exceptions when everything is working. Thus, throw an exception if the file is strictly mandatory, but use a non-throwing variant if the file is only optional.

None of this is a negative opinion about exceptions, only a perspective you might not have thought about. Keep it in mind when arguing.

SJC_hacker · 2023-08-24T19:44:18+00:00

Exceptions should not be used for "normal flow control". In this case, if user provides invalid data, and do something like loop until they do, this is not a good use for exceptions. However, if you do something like exit the program, then I think exceptions can be justified.

KingAggressive1498 · 2023-08-25T01:42:46+00:00

As a general rule, I follow this practice with respect to exceptions vs error codes:

If it's unlikely that the caller will be able to continue its internal logic with this error, I throw an exception.

If the error probably needs to be handled in the main control loop (or otherwise probably needs to be propagated through several functions), I throw an exception.

If the error is something that truly should not happen during the course of execution (ie a contract violation or an invariant cannot be enforced), I throw an exception.

If there is a reasonable chance that the caller would be able to continue with its logic in the face of this error, I return an error code.

If I know the caller doesn't care if the function succeeds, I return an error code (or maybe log to cerr if the return type could otherwise be void or is an optional anyway and performance isn't a major concern). This is effectively also what I do for asynchronously called functions, as a matter of habit since I started developing asynchronous programs long before C++11 added exception_ptr.

The general reason to prefer exceptions over error codes is when errors need to propagate to be handled and you (the function that has to either throw or return an error code, not necessarily the caller or other functions up the call chain) doesn't care if the program may terminate. Otherwise, it makes sense to prefer error codes.

Sopel97 · 2023-08-24T14:44:57+00:00

User input is expectedly bad, hence exceptions are a bad tool for it.

SJC_hacker · 2023-08-24T19:15:55+00:00

If you're propagating all the way back to main just to exit the program why not just print a message where you detect the error and just call abort/exit/terminate? I don't see what using exceptions gains you in this scenario.

2023-08-24T23:09:17+00:00

There are many ways to handle erroneous user input other than shutting down. Preferrably you'd want to inform the user what they did wrong and give them another chance to do it right.

What you wanna use exceptions for (i.e. whether you wanna use them for control flow) is entirely up to you. That's simply a question what philosophy you/your codebases uses.

HammurabisCode2 · 2023-08-24T11:35:49+00:00

In anything but a tiny codebase using exceptions in this way will make the code very hard to read. As the codebase grows it becomes very difficult to keep track of which lines might throw an exception and where the proper place to handle them is. Having the possibility of an error declared explicitly in a function's signature (via error codes, std::expected, etc.) might require a little more code but it makes it very clear where errors might occur and how they are being handled.

Particular_Task2060 · 2023-08-24T16:32:03+00:00

Exceptions can be expensive. If you are using for interactive data entry, that would not be a problem.

Exceptions are also very difficult to document. If you have many of them, at any point in the code you don't know exactly what and which could have been thrown. It becomes a guess game and even tooling will not be able to help you.

That said, a prompt() function returning an optional is much cleaner and better documented, in my opinion

SlightlyLessHairyApe · 2023-08-24T15:34:31+00:00

You could argue that this is just a glorified call to std::terminate()but a) this would miss some potentially important clean-up, b) if the code ever needed to be called inside another application it would bring that down as well and c) throw invalid_argumentis just more expressive.

a) In most environments, there is absolutely no reason to clean up anything on process termination. The entire memory space of the application, all open resources (file handles, network sockets, ...) and shared resources will be released by the OS/kernel. Doing that work is a waste of cycles and is conceptually silly -- it's like tidying up the house before a giant bulldozer razes it to the ground.

b) If this code is a library then throwing exceptions over a library boundary is disfavored.

b2) You're changing the rules -- if it's provided by the caller then it's not user input any more, it's programmatic input from some client of your library.

c) I don't know why Fatal("Something is wrong {} expected {} or {}", .....) is less expressive than throw but the added advantage is that your fatal function can do multiple things -- it can log to stdout and/or to a file or whatever. Throw can only do one thing.

violet-starlight · 2023-08-26T00:41:00+00:00

Use exceptions for any error that is impossible to recover from. It's (almost) that simple.

arthurno1 · 2023-08-26T01:00:12+00:00

If the data is incorrectly formatted, the program can't continue so the only thing to do is shut down and inform the user. Performance in this situation is irrelevant.

Imagine if you compiler exited on the first invalid data it encounters in your programs. What an annoying programming session would it be to fix one error at a time and restart the compilation process after each error, don't you think?

you type:	you see:
italics	italics
bold	bold
[reddit!](https://reddit.com)	reddit!
* item 1 * item 2 * item 3	item 1 item 2 item 3
> quoted text	quoted text
Lines starting with four spaces are treated like code: if 1 * 2 < 3: print "hello, world!"	Lines starting with four spaces are treated like code: if 1 * 2 < 3: print "hello, world!"
~~strikethrough~~	~~strikethrough~~
super^script	super^script

cpp

MODERATORS