Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Multi-catch support #30830

Closed
brunoc107 opened this issue Apr 9, 2019 · 4 comments
Closed

Multi-catch support #30830

brunoc107 opened this issue Apr 9, 2019 · 4 comments
Labels
Out of Scope This idea sits outside of the TypeScript language design constraints Suggestion An idea for TypeScript

Comments

@brunoc107
Copy link

Hello, everyone

I've been working with typescript quite a wile since i've first found it, and it's one of the coolest piece of technology i've ever used. But I think it could be cooler if we had a better way of handling errors. I mean, we could leverage the functionality of the language's try-catch.
Sometimes we need to handle some errors in specific ways that do not apply to others and the current language does not support a more strait forward way of doing it.
Today, we need to do something like this:

try {
	// Here we throw CustomError
	someOperation();
	// Here we throw AnotherCustomError
	anotherOperation();
} catch (e) {
	if (e instanceof CustomError) {
		// Custom handling
	} else if (e instanceof AnotherCustomError) {
		// Another custom handling
	} else {
		// Default error handling
	}
}

I think it could be better. We could add support to "multi-catch" to the language. The code that follows should be transpiled to the code seen before:

try {
	// Here we throw CustomError
	someOperation();
	// Here we throw AnotherCustomError
	anotherOperation();
} catch (e: CustomError) {
	// Custom handling
} catch (e: AnotherCustomError) {
	// Another custom handling
} catch (e) {
	// Default error handling
}

What do you think about it, guys?
I think it would be a joy to see it working!

Regards :)

@nmain
Copy link

nmain commented Apr 9, 2019

This fails on at least two points from the template that you deleted:

  • This could be implemented without emitting different JS based on the types of the expressions
  • This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)

As it would require both extra runtime code to be emitted (generating if...else instanceof code for you) and for that generated code to depend on the type annotations in the source.

@RyanCavanaugh RyanCavanaugh added Out of Scope This idea sits outside of the TypeScript language design constraints Suggestion An idea for TypeScript labels Apr 9, 2019
@brunoc107
Copy link
Author

I did read the template, and I was aware of that violations, but I thought the benefit of this approach to write error handling code should be exposed.
Anyway, its understandable that a feature can't enter to the project if it violates the project rules.
Just thought I should give it a try :)

@mikoloism
Copy link

mikoloism commented Mar 2, 2023

@brunoc107 I think this is a good suggestion, but in parsing we can't handle developer code and parsing code!

But maybe we can add a new try/catch keyword like try/match or whatever, what do you think?

@brunoc107
Copy link
Author

@mikoloism It could be a valid way of allowing "multi-catch" support. I think that would solve the "problem" I had when I first open this issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Out of Scope This idea sits outside of the TypeScript language design constraints Suggestion An idea for TypeScript
Projects
None yet
Development

No branches or pull requests

4 participants