>
> One ought to be able to write something like this:
>
> \`\`\` julia
> try f()
> catch e::N…oMethodError
> # handle no method error
> catch e::SomeOtherError
> # handle some other error
> catch e
> # handle any thrown object
> end
> \`\`\`
>
> Although it needn't actually be implemented by creating a generic function, this should probably emulate the behavior of dispatch, implying that clause order doesn't matter.
TLDR: it was rejected in 2012 since `rethrow()` is semantically sufficient (this is just syntactic sugar), but in 2022 @StefanKarpinski is at least vaguely supportive. But someone needs to submit the PR, which would involve:
1. Changing the parser to parse this syntax
2. Changing the lowering to lower this syntax to a sequence of `if … rethrow() …` statements.
---
### Author:  [@DNF](https://discourse.julialang.org/u/DNF)
#### Post date: [July 20, 2023, 8:34pm UTC](https://discourse.julialang.org/t/new-syntax-suggestion-catch-with-type-specs/101840/6 "2023-07-20T20:34:51Z")
Yeah, that’s it.
> [@stevengj](#):
>
> TLDR: it was rejected in 2012 since `rethrow()` is semantically sufficient (this is just syntactic sugar),
Yes, and the same goes for `switch/case`. It’s unnecessary, just much _nicer_.
---
### Author:  [@jar1](https://discourse.julialang.org/u/jar1)
#### Post date: [July 20, 2023, 8:40pm UTC](https://discourse.julialang.org/t/new-syntax-suggestion-catch-with-type-specs/101840/7 "2023-07-20T20:40:24Z")
I am opposed to this change because it encourages the use of exceptions for expected errors. IMO exceptions should be used for unexpected errors, and another system should be introduced for producing and handling failure values. Python uses exceptions for control flow; I don’t think Julia should.
Meanwhile `switch`/`case` is a primitive implementation of pattern matching, which has been implemented much more generally with [`@match`](https://thautwarm.github.io/MLStyle.jl/latest/syntax/pattern.html).
---
### Author:  [@DNF](https://discourse.julialang.org/u/DNF)
#### Post date: [July 20, 2023, 9:16pm UTC](https://discourse.julialang.org/t/new-syntax-suggestion-catch-with-type-specs/101840/8 "2023-07-20T21:16:18Z")
For my use cases `@match` is overpowered and lacks the single interesting quality of `switch/case`, which is syntactical convenience. I can just as well use `if/elseif/elseif` then.
---
### Author:  [@jar1](https://discourse.julialang.org/u/jar1)
#### Post date: [July 20, 2023, 9:29pm UTC](https://discourse.julialang.org/t/new-syntax-suggestion-catch-with-type-specs/101840/9 "2023-07-20T21:29:11Z")
What is the proposed switch/case syntax?
---
### Author:  [@DNF](https://discourse.julialang.org/u/DNF)
#### Post date: [July 20, 2023, 9:30pm UTC](https://discourse.julialang.org/t/new-syntax-suggestion-catch-with-type-specs/101840/10 "2023-07-20T21:30:58Z")
I don’t have one. I like Matlab’s, except it’s a shame to need two reserved keywords.
---
### Author:  [@jar1](https://discourse.julialang.org/u/jar1)
#### Post date: [July 20, 2023, 9:39pm UTC](https://discourse.julialang.org/t/new-syntax-suggestion-catch-with-type-specs/101840/11 "2023-07-20T21:39:21Z")
[Matlab](https://www.mathworks.com/help/matlab/ref/switch.html)
```julia
switch n
case -1
disp('negative one')
case 0
disp('zero')
case 1
disp('positive one')
otherwise
disp('other value')
end
```
[MLStyle](https://thautwarm.github.io/MLStyle.jl/latest/syntax/pattern.html)
```julia
@match n begin
-1 => display("negative one")
0 => display("zero")
1 => display("positive one")
_ => display("other value")
end
```
---
### Author:  [@DNF](https://discourse.julialang.org/u/DNF)
#### Post date: [July 21, 2023, 4:24am UTC](https://discourse.julialang.org/t/new-syntax-suggestion-catch-with-type-specs/101840/12 "2023-07-21T04:24:49Z")
I prefer the former, especially when each case has multiple lines of code.
---
### Author:  [@mrufsvold](https://discourse.julialang.org/u/mrufsvold)
#### Post date: [July 21, 2023, 4:50am UTC](https://discourse.julialang.org/t/new-syntax-suggestion-catch-with-type-specs/101840/13 "2023-07-21T04:50:44Z")
I agree with you in principle, but the reality is that, without an Option Type or some other integrated Error Type system, a lot of code does throw and need to be caught. I even saw a discussion here not that long ago about the performance of checking `hasmethod` vs just running the function and catching the `MethodError` and the latter was better.
As a 2.0 design question, moving to unwrapping with a match makes a lot of sense, but as it stands, it would be really nice to unpack errors with a switch.
---
### Author:  [@jules](https://discourse.julialang.org/u/jules)
#### Post date: [July 21, 2023, 5:16am UTC](https://discourse.julialang.org/t/new-syntax-suggestion-catch-with-type-specs/101840/14 "2023-07-21T05:16:05Z")
I guess you could get close with a macro using `if else` blocks?
Something like
```julia
@switch n if -1
println("negative one")
elseif 0
println("zero")
elseif 1
println("positive one")
else
println("other value")
end
```
---
### Author:  [@DNF](https://discourse.julialang.org/u/DNF)
#### Post date: [July 21, 2023, 5:25am UTC](https://discourse.julialang.org/t/new-syntax-suggestion-catch-with-type-specs/101840/15 "2023-07-21T05:25:03Z")
Yeah, that’s a bit better.
---
### Author:  [@HanD](https://discourse.julialang.org/u/HanD)
#### Post date: [July 21, 2023, 6:46am UTC](https://discourse.julialang.org/t/new-syntax-suggestion-catch-with-type-specs/101840/16 "2023-07-21T06:46:00Z")
> [@dylanxyz](#):
>
> I think it would be trivial to implement this feature if Julia had built in pattern matching.
True, but id doesn’t. So I deliberately avoided mentioning pattern matching, and stuck to a construct that is fundamental to Julia: type based dispatch.
> [@jar1](#):
>
> I am opposed to this change because it encourages the use of exceptions for expected errors. IMO exceptions should be used for unexpected errors, and another system should be introduced for producing and handling failure values. Python uses exceptions for control flow; I don’t think Julia should.
This would be an interesting topic to debate. I tend to disagree with you. First, if anything encourages the use of exceptions for expected errors it’s the library functions that signal errors using exceptions (such as missing files). Second, it is often the case that certain types of errors need to be handled as and where they occur (and in this case, I agree with you, using return values for this is better design), some other errors, however, only need to be addressed near the top level of the code base. Exceptions have been invented just for that. Third, the pattern I started my question with is already prevalent, my suggestion merely offers a nicer syntax for writing the same thing. Discouraging something by making it deliberately ugly is not the way to go, IMHO.
> [@stevengj](#):
>
> TLDR: it was rejected in 2012 since `rethrow()` is semantically sufficient (this is just syntactic sugar), but in 2022 @StefanKarpinski is at least vaguely supportive. But someone needs to submit the PR, which would involve:
>
> 1. Changing the parser to parse this syntax
> 2. Changing the lowering to lower this syntax to a sequence of `if … rethrow() …` statements.
Thanks for the heads up, at least now I know where to look for it.
---
### Author:  [@aplavin](https://discourse.julialang.org/u/aplavin)
#### Post date: [July 21, 2023, 7:42am UTC](https://discourse.julialang.org/t/new-syntax-suggestion-catch-with-type-specs/101840/17 "2023-07-21T07:42:14Z")
> [@mrufsvold](#):
>
> I even saw a discussion here not that long ago about the performance of checking `hasmethod` vs just running the function and catching the `MethodError` and the latter was better.
I believe `hasmethod` and others will become zero-cost in 1.10.
---
### Author:  [@aplavin](https://discourse.julialang.org/u/aplavin)
#### Post date: [July 21, 2023, 7:43am UTC](https://discourse.julialang.org/t/new-syntax-suggestion-catch-with-type-specs/101840/18 "2023-07-21T07:43:14Z")
Regarding the type-based catch approach, its details need to be carefully thought out in light of [GitHub - JuliaServices/ExceptionUnwrapping.jl: "I started by producing, and the rapping came second to that, because I wanted to fill out the beat." - Awkwafina](https://github.com/JuliaServices/ExceptionUnwrapping.jl) and concerns voiced there.
---
### Author:  [@mkitti](https://discourse.julialang.org/u/mkitti)
#### Post date: [July 21, 2023, 5:57pm UTC](https://discourse.julialang.org/t/new-syntax-suggestion-catch-with-type-specs/101840/19 "2023-07-21T17:57:47Z")
Let’s figure out how to make this happen with a macro.
Here’s the closest valid syntax.
```julia
@errdispatch try
# do something
catch e
e::AssertionError -> println("AssertionError")
e::InexactError -> println("InexactError")
end
```
To be continued…
---
### Author:  [@mrufsvold](https://discourse.julialang.org/u/mrufsvold)
#### Post date: [July 21, 2023, 8:28pm UTC](https://discourse.julialang.org/t/new-syntax-suggestion-catch-with-type-specs/101840/20 "2023-07-21T20:28:22Z")
Sorry for the tangential question, but how do you get a macro to keep capturing after a line break without a `begin`?
[Next page](https://discourse.julialang.org/t/new-syntax-suggestion-catch-with-type-specs/101840.md?page=2)