Hello! When using exceptions and try-catch blocks, it’s very common to handle some specific types of exceptions, and propagate everything else. Here’s how this is usually done: try # body with potential exceptions catch e if e isa AssertionError # handle assertion errors here e…

[image] HanD: You’re perfectly right. How about this form then, to emphasize dispatch, but to reduce boilerplate? try catch e @dispatch_error e begin e::AssertionError -> println("AssertionError") e::InexactError -> println("InexactError") end end Update: It doesn’t hav…

This latter form would essentially replicate Match.jl or Rematch.jl behavior: try ... catch e @match e begin e::AssertionError => println("AssertionError") e::InexactError => println("InexactError") end end So I guess it would be superfluous in this form.

There is a very important difference with the macro I published above. It uses multiple dispatch rules and order does not matter. My sense at the moment is that Match.jl and Rematch.jl will match against the first pattern. My method above will use multiple dispatch rules and likely require dynamic m…

You’re perfectly right. How about this form then, to emphasize dispatch, but to reduce boilerplate? try catch e @dispatch_error e begin e::AssertionError -> println("AssertionError") e::InexactError -> println("InexactError") end end Update: It doesn’t have to be called @di…

[image] HanD: @dispatch e begin e::AssertionError -> println("AssertionError") e::InexactError -> println("InexactError") end And based on your implementation, here’s how I would do it: macro dispatch(expr, body) @assert(body isa Expr && body.head == :block, "begin ..…

[image] jar1: Matlab switch n case -1 disp('negative one') case 0 disp('zero') case 1 disp('positive one') otherwise disp('other value') end MLStyle @match n begin -1 => display("negative one") 0 => display("zero") 1 => display("positiv…

Common Lisp has case and typecase which might be nicer when matching against types (as in this case): (typecase error (simple-error "not so bad") (serious-condition "must leave now") (t "giving up on default))

As long as we’re debating syntax, I would offer something like y = try sqrt(x) catch e::DomainError zero(x) catch e::Union{MethodError, AssertionError} println("unhelpful remark") rethrow(e) #= implicit rethrow for non-caught types catch e::Any rethrow(e) =# finally println("at least it's ove…

[image] mikmoore: As long as we’re debating syntax, I would offer something I don’t see how your suggestion is different from mine (your example makes a few details more explicit, but it seems to be the same otherwise), but as long as we’re on the same track, I’m happy with it. [image] mi…

I like the syntax you and @mikmoore proposed. I am thinking about the question of catching the first matching or the closest matching exception type. It seems that catching the first matching is quite simple to implement: the new syntax would be just a syntactic sugar that would expand to the if-co…

My main takeaway from this thread is that we should not implement the multiple catch block syntax as initially proposed because it is ambiguous. It is unclear if we want to do matching or dispatch. [image] barucden: On the other hand, catching the closest matching exception type (as in method d…

New syntax suggestion: catch with type specs

Internals & Design

Topic		Replies	Views
Please stop using `error` and `ErrorException` in packages (and Base) General Usage error	29	6727	May 2, 2019
Is there a better way to do error handling on Julia than try/catch? General Usage	19	10641	March 15, 2019
Use exceptions vs other patterns? General Usage	22	440	October 3, 2024
Dynamic dispatch in `catch` clauses General Usage	1	590	June 15, 2017
[ANN] ErrorTypes.jl - Rust-like safe errors in Julia Package Announcements rust	14	2750	October 6, 2021

New syntax suggestion: catch with type specs

Related topics