Using exceptions for error-free purposes

Question

Is it good to use an exception to manage cases that are not errors?

Both in JavaScript and Python, which control the StopIteration event in generators (yield keyword).

Answer 1

It depends on the language. Each language has its own design and idioms. For most languages, exceptions should be exceptional.

In languages ​​like C ++, Java, and C #, a very poor form of using exceptions for anything else.

In Python, exceptions are used more often for things like end of iteration. There are many more models for doing what you want and handling exceptions later, rather than checking input ("It's easier to ask forgiveness than permission"). For example, if you want to open a file, in Java you can check if it exists first, and then open it and check if you have a valid stream. In Python, you open it and use. If this fails, you are throwing an exception.

From the wikipedia article:

The Python style causes the use of exceptions whenever an error condition occurs. Instead of testing access to a file or resource before actually using it, in Python you usually just go and try to use it, catching the exception if access is denied.

Exceptions can also be used as a more general way of non-local transfer of control, even if the error is not a problem. For example, Mailman's mailing list software written in Python uses exceptions to jump out of the deeply nested message processing logic when it was decided to reject the message or hold it for moderator approval.

Answer 2

I would say no, spontaneously. Exceptions should be used for exception states, and not for normal program flow.

Answer 3

Not usually, no. ASP.NET uses this for Response.Redirect - actually interrupting the stream and then catching the exception and dropping it. This is very unpleasant, but it allows you, in principle, to "exit" with a request without any stack level, realizing that he needs to return immediately.

Try to avoid where possible. If you think that you absolutely need to do this, contact your two colleagues, introduce the design and ask if they can do it more cleanly. If none of you can think of a better way around it, do this with extensive documentation.

Answer 4

As the name implies, exceptions should be used only in exceptional cases. I would not use it for error management.

Answer 5

Not.

Exceptions should only be used in exceptional situations (as the name says). This means: errors.

• "Uh, I can't find this file." - An exception!
• "Uh, I can't divide by 0." - An exception!
• "Uh, I can't get a memory." - An exception!
• "The result is 2.5." - Not an exception!

Answer 6

This is a very dubious practice. If you think this is best for your situation, be sure to fully document and comment on this to save WTF / m .

Answer 7

In the sudoku solver that I wrote, an exception is thrown if the puzzle is solved.

The main search function, a private method, is dropped into the search tree, making recursive calls for itself. The usual case is the inability to solve the puzzle, which leads to a normal appeal to the caller; the exceptional case is success in solving the puzzle, in which case we “throw (the solution)” all the way out into the catch clause in a public method.

Something like this is a well-known idiom on a Schema using call / cc. I mimicked this in my C ++ program.

I would be happy to hear someone for or against an opinion on this approach.

Answer 8

Not.

As a rule, the system is designed to quickly execute exceptions, while the adoption of exceptional cases leads to a performance hit. Thus, the many exceptions that will be thrown / caught will be slower than regular constructs.

It also makes code analysis and understanding more difficult, and most of the code spends most of its time on maintenance.

Answer 9

I find that sometimes exceptions are useful for building DSLs . I know this sounds strange, but since many languages ​​don’t have Ruby functions (the return keyword is optional because the result of the last processed expression is returned), we use what we can.

For example, I recently tried to create a small JavaScript testing platform, and I wanted infrastructure users to be able to say:

 skip(); pending("pending message"); fail("failure message"); 

instead:

 return skip(); return pending("pending message"); return fail("failure message"); 

These functions would be library functions that throw exceptions, such as a SkipTest exception. The only recommended place to use them is inside test methods. These test methods are always executed in the try / catch block, where each type of exception is processed, and, depending on the exception, the environment takes the appropriate step.

This is an example when I used Exceptions for control flow.

Here is a small example:

 $.it("should offer means to explicitly mark a spec as failed", function() { $.fail("this spec must fail"); });