Deprecate error("msg")?

[c42f]

I've just been in contact with a new user, who was understandably using throw("my message") rather than throwing an ErrorException via error().

Do we need the conceptual overhead of having both error and throw? Why not conceptually have the following definitions:

throw(msg::AbstractString) = throw(ErrorException(msg))
throw(e::Exception) = builtin_throw(e)

A somewhat related question - what do we gain by allowing people to throw things which aren't subtypes of Exception?

[andyferris]

I've wondered if throw("...") would be better, also.

[cstjean]

A somewhat related question - what do we gain by allowing people to throw things which aren't subtypes of Exception?

In Common Lisp, it's accepted to use throw to return values from a deeply nested context, and it's sometimes much more convenient than passing the computation result through many functions.

[c42f]

I remember seeing this proposed before, and after some digging I found the comment by @kmsquire #13515 (comment)

[ararslan]

throw throws an Exception object. throw(::String) doesn't make sense conceptually; it would have to be throw(ErrorException(::String)). But if you don't have an appropriate error type to use, just saying error is much cleaner.

[c42f]

You can, in fact, currently throw a string without wrapping it in an ErrorException,

julia> typeof(try ; throw("asdf") ; catch ex ; ex end)
String

The observation here is that this probably doesn't make a whole heap of sense, so we have the opportunity to turn two verbs into one by just removing error. It seems like a good pun to me.

[yuyichao]

I don't think we should try to guess what the user want. We are in general moving away from error so I'll be fine to deprecate that. Allowing throwing a string and not actually throwing it is encouraging bad coding style.

[cstjean]

We are in general moving away from error so I'll be fine to deprecate that.

Why?

[yuyichao]

It offers no information of what actually happens.
Usually the error can be replaced with ArgumentError (which roughly corresponds to pythong's ValueError) if it doesn't fit in any other category.
We don't have a good type hierarchy for exceptions yet but we still should not encourage throwing the most general error possible.

[c42f]

I'd be content to simply deprecate error, though I still prefer the option of overloading throw. This is no more "guessing what the user wants" than all the other uses of multiple dispatch in julia.

The argument that we should encourage users to throw more specific exception types holds more weight.

[yuyichao]

This is no more "guessing what the user wants" than all the other uses of multiple dispatch in julia.

No. Multiple dispatches should not be used that way. Multiple dispatch is generally used to select the best implementation and not completely changing the behavior.

[c42f]

Multiple dispatch is generally used to select the best implementation and not completely changing the behavior.

What do we gain by allowing users to throw things which are not subtypes of Exception? If the answer is "nothing", we can also deprecate that, and there would be no conceptual ambiguity here.

I agree that this is a change of behavior, and the deprecation would need to be handled correctly in stages.

[yuyichao]

there would be no conceptual ambiguity here.

There is. Instead of giving an error you want it to do something that shouldn't be encouraged.

[andyferris]

So to recap, my own interpretation of the proposal is this:

• deprecate error
• ensure that throw always ends up throwing something which is a subtype of Exception (or more precisely, that catch always receives an Exception).
• however, if the user passes something that is not a subtype of Exception to throw (perhaps just a String), it automatically gets wrapped in ErrorException, for convenience.

In the last point, I see this as more-or-less "sugar" (it's not literally syntax sugar; we could use dispatch to arrange this) so that in the cases you want to be lazy, you can. Now, I do understand that it's much better practice to use the corresponding Exception type - but you have to admit that there are times that you are writing a hacky script and want to do it quickly but you want some useful error message at some point, and writing throw(ErrorException("...")) is too much overhead in my opinion. And I've found we don't have good exceptions for a lot of situations.

The consequences are that this "lispy" style of breaking through multiple stack frames by throwing whatever data type you want might not work as now. However, to make that safe, I think it would be better practice to make your own Exception subtype to explicitly mark and carry that information.

[yuyichao]

but you want some useful error message at some point, and writing throw(ErrorException("...")) is too much overhead in my opinion.

If people just want this, then we should keep error and clearly document that it shouldn't be used to show user errors. FWIW, for writing something quick, @assert is usually good enough. I usually only switch away from it if I want the code to be more permanent in which case I'll pick the right error type. (which would be ArgumentError most of the time since I'm just checking input ranges).