Is it a good practice to use exception for managing cases that are not errors ?
Like in JavaScript and Python that manage the StopIteration case in generators (yield keyword).
Is it a good practice to use exception for managing cases that are not errors ?
Like in JavaScript and Python that manage the StopIteration case in generators (yield keyword).
I would say No, spontaneously. Exceptions should be used for exceptional states, not for regular program flow.
Not usually, no. ASP.NET uses this for Response.Redirect
- actually aborting the thread, then catching the exception and resetting it. It's very nasty, but it does let you basically "quit" the request without every level of the stack being aware that it needs to return immediately.
Try to avoid wherever possible. If you think you absolutely have to do it, consult two colleagues, present the design and ask if they can do it more cleanly somehow. If none of you can think of a better way round it, do it with extensive documentation.
As the name says exceptions should only be used in Exceptional cases. I would not use it for managing non error cases.
No.
Exceptions should only be used for exceptional situations (as the name says). That means: errors.
No.
Generally the system is designed to make non-exception cases fast, while accepting exceptional cases take a performance hit. Thus a lot of exceptions being thrown/caught will be slower than conventional constructs.
It also makes analysis and understanding the code harder, and most code spends most of its time in maintenance.
It depends on the language. Each language has it's own design and idioms. For most languages exceptions should be exceptional.
In languages like C++, Java and C# it is very bad form to use exceptions for anything else.
In Python, exceptions are used more frequently for things like the end of an iteration. There is much more of a model of try to do what you want and handle the exceptions later rather than validating input ("Easier to Ask Forgiveness than Permission"). For example if you want to open a file, in Java you might check if it exists first and then open it and check to see if you have a valid stream. In Python you would open it and use it. If that fails you handle the exception.
From the wikipedia article:
Python style calls for the use of exceptions whenever an error condition might arise. Rather than testing for access to a file or resource before actually using it, it is conventional in Python to just go ahead and try to use it, catching the exception if access is rejected.
Exceptions can also be used as a more general means of non-local transfer of control, even when an error is not at issue. For instance, the Mailman mailing list software, written in Python, uses exceptions to jump out of deeply-nested message-handling logic when a decision has been made to reject a message or hold it for moderator approval.
I believe that sometimes exceptions are useful for building DSLs. I know, it sounds weird, but as many languages don't have the features Ruby has (the return keyword is optional because the result of the last evaluated expression is returned), we use what we can.
For example, I recently tried to build a little JavaScript testing framework, and I wanted a way for the framework users to be able to say:
skip();
pending("pending message");
fail("failure message");
instead of:
return skip();
return pending("pending message");
return fail("failure message");
These functions would be library functions which throw exceptions like a SkipTest exception for example. The only recommended place to use them is inside test methods. These test methods are always executed in a try/catch block where every type of exception is treated and, depending on the exception the framework takes the appropriate step.
This is an example where I've used Exceptions for control flow.
Here's a small example:
$.it("should offer means to explicitly mark a spec as failed", function() {
$.fail("this spec must fail");
});
I've seen Python code that uses exceptions to test if input is of the correct type
try:
n = int(n1)
except (ValueError, TypeError):
# return an eror
Is this poor form, or does it qualify as an "exceptional case"?
In a sudoku solver I wrote, an exception is thrown in case the puzzle is solved.
The main search function, a private method, descends into the search tree by making recursive calls to itself. The normal case is failure to solve the puzzle, which results in just a normal return to the caller; the exceptional case is success in solving the puzzle, in which case we "throw(solution)" all the way out to a catch clause in a public method.
Something like this is a known idiom in Scheme, using call/cc. I was imitating that in my C++ program.
I'd be delighted to hear anybody's pro or con opinions on this approach.