Exceptions

[Rashad2]

Questions about exceptions. Do programmers actually use this in the real world? When i get a job will i ever use it? It seems unnecessary.

[coder777]

Do programmers actually use this in the real world?

Yes

When i get a job will i ever use it?

Depends on where you work, but propably yes.

It seems unnecessary.

Not only that. It's also slow and defies a clean program flow.

For a creator of a library it's perfect: All you have to do is throw and you're done with the error.
The trouble is on the user side. The one who throw nows exactly why and what, just the one who catch mostly not.

[TheIdeasMan]

http://www.stroustrup.com/bs_faq2.html#exceptions-why

https://isocpp.org/wiki/faq/exceptions

As coder777 mentioned, it's easy. The alternative is return codes - which is a nightmare (a rats nest of tests as mentioned in the articles)

Also, they seem essential to me - especially in initialiser lists: what to do when construction of a base class throws, or indeed the creation of some other object fails? Answer - put a try into the initialiser list.

http://www.cprogramming.com/tutorial/initialization-lists-c++.html

The pertinent bit is about 2/3 the way down the article.

Hope all goes well :+)

Edit :

http://www.gotw.ca/gotw/066.htm

Edit 2:

When I said it was easy, I meant easier than return codes.

[tcs]

But you should only use them to signal error conditions and not, as I've seen once, as mechanism of regular (unexceptional) program flow.

[Computergeek01]

Exceptions can be as fast or as slow as you make them. It's when code monkey's start putting them everywhere and anywhere for no other reason then "that's what they were taught to do" that it becomes a mess. They are essentially a controlled jump statement so in that sense they are a fast operation for the system to process. The trouble is that it is too easy to fall into the trap of nesting too many try catch blocks within one and another and that is where the stack unwinding becomes a problem because each catch has to evaluate the thrown error and either deal with it or pass it on up the chain. It only takes about ten seconds of thought to realize that this is just a common failed design consideration and not an actual problem with this feature.

Another mistake people make is not thinking about whether or not exceptions are actually needed in their code, they will either just return from the function on error or they will set some error value, throw an exception to break normal flow, catch it and return the error code. Both are equally stupid. Anytime you have resources that do not have automatic storage duration, i.e. anything that was dynamically allocated or does not have a destructor such as objects that were imported from a C style library, these resources will probably need to be manually cleaned up. Exceptions allow you to place all of the relevant clean-up code at the end of a function where it would normally have to be anyway so that you don't end up typing the same thing a dozen times at each potential failure point.

Programming is a field that requires you to think about each problem in front of you without making half-assed blanket assumptions about how to approach them. If you're the kind of person who looks at a core feature of any language and thinks "I'll just never use that because I don't see the point." then the world would be a better place if you found something else to pursue.

[dhayden]

In my work I write daemon processes that run for weeks or months at a time in a large distributed system. It's essential that the code handles all error cases. I usually don't use exceptions for several reasons:
- the calling code usually isn't set up to handle an exception. Also, there's no way to tell the caller that it has to handle one. What this really boils down to is that using exceptions requires that all the software is exception safe.
- The right way to handle an error is different in each place where an error occurs. Put another way, some people complain that return codes create a nightmare, but the reality is that you need the code to handle each case anyway.
- Often an error happens in some low level function and you have to deal with it much higher up in the call stack. It would seem that this is a great opportunity for an exception, but in reality you need to know the context of that whole call stack to diagnose the error. In other words, it doesn't help if a program says "client can't contact server." What you really need is "xyz client can't contact config server when trying to get configuration value QRS: call timed out. So each level has to handle the exception anyway.
- I like to call exceptions "invisible variable goto." It's like using goto with a variable as the label. They've avoided putting this into the standard because it breaks structured programming. And it's invisible in the sense that calling a function f() can result in flow of control transferring anywhere. They realized about 50 years ago that unstructured flow of control was a really bad idea. Exceptions throw that away.

Even in this environment, I've used exceptions in cases where I'm doing the same sort of thing over and over, the failure results in the same path and the error & error handling code are close to each other.

I think what it boils down to is that production code can make good use of exceptions if the code is designed for them from the ground up.

[TheIdeasMan]

@dhayden

Hi,

Just a question to help my education a little. It's always good for dabblers like me to get insight from a professional programmer :+D

My main reason for asking about this is that constructors and overloaded operators cannot return anything.

In your environment, could you still throw from a constructor so that the object isn't created thus avoiding having an invalid object? To avoid the exception being propagated, I guess one would have to avoid having constructor arguments that create other objects that in turn might fail. In other words, create objects first, if that works then use them as arguments in a constructor call. Would this be a valid use of an exception in your environment?

- The right way to handle an error is different in each place where an error occurs. Put another way, some people complain that return codes create a nightmare, but the reality is that you need the code to handle each case anyway.

I can't help thinking that one would throw different exceptions to cover each case. Is this nearly the same thing? Or am I looking at it wrongly?

- Often an error happens in some low level function and you have to deal with it much higher up in the call stack. .......

I can see how it would be a pain to invent some kind of exception class to cover every possibility, with the idea that new info is added to it as it passed upwards - I wonder if it would be better if C++ allowed throw with multiple arguments? That way it would be easier to have a diagnostic like

"xyz client can't contact config server when trying to get configuration value QRS: call timed out."

Just an idea - no clues on how good it is or how well it would fly.

Hope all is well at your end :+)

[dhayden]

In your environment, could you still throw from a constructor so that the object isn't created thus avoiding having an invalid object?

That would only be practical with new code that we wrote since the caller would have to be prepared to catch the exception. Modifying an existing class to throw an exception in the constructor could be a firing offense if the class was heavily used since it would require finding EVERY single place in the code where the class was instantiated and making sure that the exception was handled.

I can't help thinking that one would throw different exceptions to cover each case.

The issue isn't which exception is thrown. You could throw an int each time and just pick different values. The issue is catching the exception and dealing with the error.

I wonder if it would be better if C++ allowed throw with multiple arguments?

I think that would just make matters worse and it probably wouldn't be necessary. When you throw an exception you're dealing with some error, not several. The way we handle adding details as we unwind the stack is to append them to a global error object. By the way, if anyone ever tells that you that globals are horrible and must be avoided at all costs, ask them why std::cin and std::cout are global. The truth is that some things really do need to be global if they represent the global context of the program.

Hope all is well at your end :+)

You too! I don't recall which post it was, but you recently posted something that I found very intriguing and spent some time tracking down the details. Thanks, and Happy Thanksgiving.