throw vs error

[Michele Zaffalon]

In what cases should one use error() instead of throw()? The manual is not particular clear about the difference:

The error() function is used to produce an ErrorException that interrupts the normal flow of control.

Isn't what throw is supposed to do?

[Isaiah Norton]

`error` is generic, whereas `throw` can raise typed errors, such as DomainError, SimdError, UVError, etc. which may have special handling -- for example, customized `show` methods to print help/suggestions to resolve the specific situation.

(see also the examples here: http://docs.julialang.org/en/latest/manual/control-flow/?highlight=error#the-try-catch-statement)

[Michele Zaffalon]

That is my point: error is the same as throw(ErrorException). Should both co-exist? Is error just a short name for the throw(ErrorException) version?

[Isaiah Norton]

Yes.

[Stefan Karpinski]

This is actually an old debate between me and Jeff. The distinction I tried to make was that `throw` should be used with catch as a form of control flow, while `error` should be used when there's an actual error. However, that distinction hasn't stuck, possibly because he never liked it and it's common to see `throw(InexactError())` in Base. We could get rid of `error` but writing `throw(ErrorException("oops"))` to throw a simple error seems pretty unpalatable.

[Michele Zaffalon]

Verbosity aside, (which may also be disputable since errors are supposed to be rare...), I still do not see the difference even from reading the constructed examples in the manual: both are examples of functions that are not defined for negative arguments, but in the first case, the function throws an exception, in the second it signals an error.

michele

[Stefan Karpinski]

Not sure how that's really a response to what I said, which acknowledges that it's an ambiguity...

[Michele Zaffalon]

You are right, my reply was unnecessary.

[Stefan Karpinski]

No worries, if you've got any bright ideas how we should resolve this throw/error thing...

[Michele Zaffalon]

Bright ideas? I am afraid not.

Had you said dumb ideas, I would have suggested either to remove it completely, leave it as a shortname for throw(ErrorException) or to replace with something that cannot be caught, but for this one I cannot suggest a use case (maybe writing way past array boundaries when using @inbounds?)

[Jeffrey Sarnoff]

Calling error("message") should report an error from the function in which it is called, and it would be helpful to show the call chain. Currently, calling error reports an error from the top of the call chain, the function generating the error is not shown. Throwing an exception is either caught and handled, caught and rethrown, or uncaught. Uncaught, it should travel up the call chain -- looking to be caught, and remembering the calls it traverses in reverse; at the top level, report it as an uncaught exception with the call chain.

If it is thrown, it presumed handleable and so it is an exception.  If it called and not thrown, it is presumed unhandleable and so it is an error.

[Michele Zaffalon]

to replace with something that cannot be caught, but for this one I cannot suggest a use case (maybe writing way past array boundaries when using @inbounds?)

Maybe a better example for something that should not be possible to catch is an assertion error.

[ele...@gmail.com]

On Monday, August 24, 2015 at 12:38:10 PM UTC+10, Michele Zaffalon wrote:

 

to replace with something that cannot be caught, but for this one I cannot suggest a use case (maybe writing way past array boundaries when using @inbounds?)

Maybe a better example for something that should not be possible to catch is an assertion error.

But then catching assertions is useful for test code that deliberately triggers them.

[Michele Zaffalon]

to replace with something that cannot be caught, but for this one I cannot suggest a use case (maybe writing way past array boundaries when using @inbounds?)

Maybe a better example for something that should not be possible to catch is an assertion error.

But then catching assertions is useful for test code that deliberately triggers them.

I thought the meaning of assertion is "I strongly believe that at this point in the program this statement is true; if not, something is really wrong and I had better should stop immediately before other damage occurs". This could happen because not all possible error situations were considered.

For code testing, exceptions should be triggered instead: trying to open a non existing file? throw(FileNotFoundError)? square root of negative number? DomainError and so on.