best way for error handling

[near hinge]

I got many classes in my project. Some of them can fail during construction. For that i need to use throw. How can i give ide warnings?

[lofty gulch]

don't think you can, because

• ts and eslint aren't aware of what can and can't throw, generally it's treated as if anything can throw so it's not warned
• if they could check for that, then they wouldn't know if they should warn or if bubbling up is the intended behavior.
  i think best you could do is use docs for that, for example jsdoc @throws

[near hinge]

I hoped for a different answer, those were my findings so far

There is a vscode plugin, but im mad ts has no error types until this day

[worldly coral]

What's the VSCode plugin?

I'd also like to have more info here

[near hinge]

Cqnt find it atm

Theres also this

[calm creek]

It sounds like you want checked exceptions

TS indeed doesn't have it, C# doesn't have it either, Java has it and most people consider it more annoying than useful.

I think most languages that want exceptions to be more than exceptions, opt for the "error as value" paradigm instead.

(On that note though, I'm not sure if a class constructor should ever throw, that sounds like you want a factory function instead)

[worldly coral]

Yeah I'll try it

[near hinge]

@worldly coral @calm creek @lofty gulch https://marketplace.visualstudio.com/items?itemName=michaelangeloio.does-it-throw-vscode

[worldly coral]

"Call expression tracing (Aka "Calls to Throws") is now set to one level deep. Hope to make this configurable in the future!"

Not sure it's very good unless it tracks all the way down

but thanks all the same @near hinge

[near hinge]

@worldly coral im wondering, is it not possible to write a ts plugin which would do this as well?

[worldly coral]

I've never heard of a TS plugin, in the sense of something that extends the behaviour of TS.

There are eslint plugins that using type information from TS I believe.

But a throwing function isn't a type, so not sure how that would help.

It would be possible to write it into TypeScript. But the challenge is convincing the TS maintainers to accept it.

[near hinge]

what was that website again where you can inspect how typescript computes a type again

[near hinge]

i wanna see if itsp ossible as a plugin

[worldly coral]

No clue

[calm creek]

There's no way for you to know what a function can potentially throw.

If you are thinking about analyzing a function's code to see what it throws, and then also look at all the functions it calls to see what they throw, that approach won't work because eventually you will descent down to native functions like JSON.parse, which you can't know if and what they will throw.

[near hinge]

i would mark those as protentially throwing as well

and then later provide options

i get what you're reffering to

though

[calm creek]

And not just native functions, foreign code (eg coming from a package) as well.

[near hinge]

im aware

[near hinge]

But I have a question, it would be annoying yes, but would it not be better if you can configure ts to literally handle every throw error

via a warning / error

[calm creek]

If you do that then the analysis is basically useless, because practically every function will use a native function, so the only result it gives is just "every function can throw."

[near hinge]

that would be the "max" level config, i would add a level below it for only look throws written in code

by the user

[calm creek]

Yeah at that point you should just go for the "errors as values" paradigm instead.

[near hinge]

what do i do in the case of a class creation cancellation?

I dont want to use a factory either, because then I have a factory and then the static methods on that class

[calm creek]

^

[calm creek]

Wdym by this, can you show some code why it wouldn't work for you?

[near hinge]

imagine an VElement class, that element has its own instance, reprensting as an example a html element, it has tagname, attributes etc, but then there are static methods which allow to add an event onto the entire class, like before Element creation, before attribute change etc

[calm creek]

Why would having a factory function not allow you to use static methods?

[near hinge]

because then you have to improt 2 things, and if someone ignores the factory and creates it directly it would still throw

unless i do 2 classes, in which case instanceof would be nailed

[calm creek]

No, you will write your constructor to never throw

The factory function can just be a static method on the class if you don't want to import two things.

[near hinge]

what if they create an element if an used id then?

it would NEED to throw

because that element would be invalid

or an " " tagname

i need to do some kind of validation and throw

[calm creek]

If it throws, then it's an unrecoverable error.

[near hinge]

yeah, because it is

[calm creek]

If it's unrecoverable, then there's no reason to catch it.

You just let it bubble all the way up and deal with it at the application root, by just crashing the program or log it.

The only reason you want to catch an error, is to recover.

[near hinge]

and this is the reason why I want to warn people when they use my class via the IDE

we came full circle

[calm creek]

I don't think there's anything to warn, JSON.parse doesn't warn you either and you just have to read the documentation.

[near hinge]

and that imo is bad design

[calm creek]

That's not a specific thing to JS either, in C# things can throw and you just read the documentation.

[near hinge]

I disagree with that opinion

this is why im trying to fix it for my application

[calm creek]

Well you are essentially fighting against the language.

[near hinge]

yep

the thing is, i like ts, i want to improve it further

i want my users to write even safer and better code

i know its more verbose

[calm creek]

That's a fundamental language design issue, it's extremely hard to retroactively fix that especially in user land.

[near hinge]

i agree with that

[calm creek]

Just write proper documentation like JSDoc and call it a day, people hover over your constructor will see it.

[near hinge]

i will do that anyways, but I want to try to make this plugin

I am faily certain that this would help the eco system as a whole

i can imagine that some teams would love this

even if its more verbose

I rather write more code then have a crash in prod

[worldly coral]

You just need typings of those functions. Technically you can probably get something like OOM errors from anywhere, but you'd have to ignore that.

@near hinge What are the scenarios causing construction to fail?

If empty tag name "" is an error, you can make a type that prevents that.

[calm creek]

You can't really prevent that on the type level.

[near hinge]

conflicting ids (during a file load), reffering to invalid tagnames, are two examples

[calm creek]

This is basically what https://github.com/microsoft/TypeScript/issues/13219 asks for. It's in the limbo though.

[worldly coral]

Are the tagnames just HTML element names?

[near hinge]

not nessecarily

[worldly coral]

What makes a tag name valid or invalid?

[near hinge]

custom elements, and then - check ik

[worldly coral]

So it has to be an HTML element, or a defined custom element?

[near hinge]

yeah, and i can use a union type for that

but i also have other cases where i cannot fix it like this

[worldly coral]

If your users are defining custom elements, than you have a problem knowing those custom elements right?

[near hinge]

that is not an issue, since custom elements need to be something-something

[worldly coral]

OK, so here you can use a union

[near hinge]

i know

[worldly coral]

I know you know 🙂

But yeah sometimes it won't be so easy

[near hinge]

the other thing is

should i always throw so errors are "uniform" with eachother, or should i mix throw and returns, return error where possible?

[worldly coral]

Up to you. I would aim for a constistent design that returns errors

I would also make all my errors be/extend my own error class

class SuperPackageError extends Error {}

Then it's easy to identify that an error came from the package.

[near hinge]

Ahh yeah, I will do so

i will do it similarly to trpc

[calm creek]

Throw unrecoverable errors, return recoverable errors.

[near hinge]

Yeah but i cannot do that with classes

[worldly coral]

But if you want to return errors, then you probably want to replace the constructors and static methods with all factories. I think you can return an error from a constructor, but I doubt TS will play well with that.

[near hinge]

as an example a conflicting id error can be still recovered from => no app crash

but i need to somehow cancel the class creation

so user has to handle that throw

[worldly coral]

yeah use a function to handle creation is really a good answer

[near hinge]

thats a factory, but then I have the issue regarding static methods and instanceof

[worldly coral]

static methods can be replaced with functions no?

[calm creek]

I don't get the issue with static methods and instanceof

[worldly coral]

So you want to export the class so that you can do instanceof, but you don't want it to be constructed directly

You can probably prevent direct construction

[near hinge]

via a throw

only

[calm creek]

You can make a private constructor.

[near hinge]

what

[worldly coral]

Do you have to type cast to call a private constructor?

[near hinge]

i dont even know that private constructors were a thing

[calm creek]

Nope.

[worldly coral]

So how do you create the class? static method?

[near hinge]

apparently

from what im reading

[calm creek]

Yes, private constructor is accessible by static.

[keen iris]

sandiford#0

Playground Link

Preview:```ts
class A {
private constructor() {
console.log("hello")
}
static make() {
return new A()
}
}

const a1 = new A() // err
const a2 = A.make()```

You can choose specific lines to embed by selecting them before copying the link.

[calm creek]

And you just do whatever throwing logic in make but instead make it return error.

Now you have fully type safe error handling.

[near hinge]

hmm, well, this sounds like what i need, now im only sad that I lose the new X syntax

i quite liked it

[worldly coral]

X syntax?

class A {
    private constructor() {
        console.log("hello");
    }
    static make() {
        return new A
    }
}

const a = new (A as {} as new () => A)()

this works, but it's not nice, because having to cast to {} in the middle loses all safety.

I thought it might be possible to do new (A as new () => A)() which would let you build internally using the assertion but not let A be constructed otherwise.

[calm creek]

Just do A.tryCreate() or something, it makes it even clearer that it can fail.

[near hinge]

not bad

VElement.tryCreate()

[keen iris]

class _A {
    foo = 'foo'
    constructor() {
        console.log("hello");
        return new Error('err') as unknown as _A
    }
}

const A = _A as new () => _A | Error

const a = new A()
//    ^? - const a: _A | Error

[worldly coral]

I'm not saying that you should do this, but, yeah it exists.

It's probably going to create problems

[keen iris]

sandiford#0

Playground Link

Preview:```ts
class _A {
foo = "foo"
constructor() {
console.log("hello")
if (1 > 2) return new Error("err") as unknown as _A
}
}

const A = _A as new () => _A | Error

const a = new A()
// ^?

if (a instanceof A) {
console.l
...```

You can choose specific lines to embed by selecting them before copying the link.

[worldly coral]

It kinda breaks instanceof

[near hinge]

yeah, if i go for a solution i just go for tryCreate

anything else is meh

[worldly coral]

Sure, sounds good.

[near hinge]

@worldly coral @calm creek I found that goddamn site https://astexplorer.net/

[worldly coral]

Oh yeah I know that one haha

[near hinge]

wait

doesnt this one have ts as well

[worldly coral]

It has TS

In the </> dropdown

[near hinge]

thank you

@worldly coral first time today dealing with the ast

[worldly coral]

Why are you using AST?

[near hinge]

experimenting around, I think I wanna solve this throw issue for everyone

even if i will prob use tryCreate

[worldly coral]

oh

[near hinge]

I want to try to make a system which warns you if anything can throw

testing around right now

[worldly coral]

By contributing to TypeScript or something external?

[near hinge]

a plugin later on

typescript itself stated they dont want it

and i heavily disagree

[worldly coral]

If you write a plugin, how does a person use that plugin?

[near hinge]

in the tsconfig you cna add plugins

[worldly coral]

ah, that's cool

[worldly coral]

I guess we can write wrappers for functions that throw that we can't change, and handle errors that way. But there doesn't seem to be an effort to provide that

So yes it feels like we could do with improved tooling

[near hinge]

the crazy thing is i dont feel like it should be even that hard, im roughly experimenting right now

and it already knows what try catch throw etc is

i think what i will do is just define (if possible) a new property that it can throw and which errors can throw

and always set that at the parrent

[worldly coral]

Well you'll need to create a data bank of all built in functions that can throw

[near hinge]

i will do that eventually

i start simple

[worldly coral]

And ideally we want to know what a function can throw too.

[near hinge]

exactly!

and then having a union type

automatically typed errors in try catch

oh holy moly

imagine this with zod

and other tools

[lofty gulch]

function f() {
  throw null;
}
try {
  f();
} catch (e) {
  console.error(e.toString());
}
```this would throw, that's why it's hard

[lofty gulch]

console.error itself might throw if stderr was closed

[near hinge]

LOL

well, this will be fun

[worldly coral]

This is a type error though?

e is unknown

[lofty gulch]

only with that option on, without it it's any

[near hinge]

question is now

[worldly coral]

which option?

[near hinge]

if i somehow get it running like this

would i be able to convert it to a plugin easily

or should i immedietly start via a plugin

[lofty gulch]

don't remember the exact name, something like useUnknownInCatchVariables

[worldly coral]

I have no clue. I'm starting to work on TypeScript source now, but I am a total beginner

I don't have that checked @lofty gulch

[near hinge]

@worldly coral you have contacts there whom you can ask where a beginner can learn more about writing plugins

[keen iris]

sandiford#0

Playground Link

Preview:ts function f() { throw null } try { f() } catch (e) { console.error(e.toString()) }

You can choose specific lines to embed by selecting them before copying the link.

[lofty gulch]

it's probably on with strict

[worldly coral]

here take a look

[jade yacht]

https://www.typescriptlang.org/tsconfig/#useUnknownInCatchVariables

[worldly coral]

#compiler-internals-and-api is probably the place.

[jade yacht]

And yeah, it's under strict.

[worldly coral]

Ah, so I think most people are on strict

[lofty gulch]

even so, a toString method can throw

even though most don't, same as there isn't a mechanism to check errors, there isn't a mechanism to validate that a method doesn't throw

[jade yacht]

Accessing a property can throw

[near hinge]

hell

wait

what word is ahh

the s word is banned

well then i need to configure some levels to that popo, I wanna protect the code by alot, but not unreasonable (unless ur on max level later on, enjoy then your time in hell)

[lofty gulch]

ctrl+z can restore your chatbox

[lofty gulch]

yeah well this is kinda the problem with that feature in the js ecosystem lol, what level is reasonable

[jade yacht]

const obj = {
 get soup() { throw new Error("No Soup For You") }
}

[near hinge]

that will be a discussion later on, for now just showing which functions by yourself can throw is already really big imo

[lofty gulch]

what about throws in iifes or at the top level

also, what about bubbling up

[near hinge]

iifes?

[worldly coral]

I meant this is like any throwing function though? If throw typing was implemented, that function is inferred as throwing, and you then need to make that property as able to throw.

[near hinge]

top level? can you elaborate?

[lofty gulch]

immediately invoked function expression

[lofty gulch]

a throw at a top level would make an import throw

[near hinge]

like this?

[worldly coral]

Hmm, so a module needs to have a can throw status

[lofty gulch]

yes

[near hinge]

lemme take notes

[worldly coral]

Which can't be caught I think.

aside from dynamic import

[near hinge]

you got an example for this?

[worldly coral]

(() => {
// code
}) ()

[near hinge]

hmm

[worldly coral]

I guess an IIFE just affects the enclosing scope as if it wasn't there

[lofty gulch]

or even like

if (!(process in globalThis)) {
  throw "only on node"
}

[worldly coral]

unless it's async, perhaps.

[near hinge]

@lofty gulch the question is as well, is it okay for me to pollute every parent with "unhandled throw" until a try catch or something comes along

[lofty gulch]

that's what bubbling is, yeah

[near hinge]

ahh, yeha, i wanted to do it that way

anyways

[worldly coral]

function f() { // function f inferred as a throwing function
  (() => {
    throw ('IIFE throws;)
  })()
}

[lofty gulch]

and that's not described in the code itself

[near hinge]

example?

[lofty gulch]

all code that exists

if there isn't a try/catch, it wants bubbling behavior (or it forgot that)

[near hinge]

oh

i think i understand what you mean

[lofty gulch]

gtg, ill be back

[near hinge]

yessir

[worldly coral]

I was thinking about this a while ago, and I figured that exceptions should bubble up, with each parent being inferred as a throwing function.
Ideally there would be some kind of hint that a function is not handling a possible error, like coloring throwing function that aren't handling in the current function/module.
And at the top level i.e. the module level, an unhandled error would be an error, but you could annotate to say "this module can throw", which then allows the program to terminate on throw.

[near hinge]

exactly!

i wanted to perhaps add a comment

or just have ts ignore

or ts can throw

[worldly coral]

You might want to read about Checked errors in Java

They have errors which are typed, and Exceptions which are not. Exceptions basically are going to crash the program. Errors are typed are you are expected to handle them.

The interesting thing about checked errors is A) I think that's the only language that does it and B) people don't like them very much.

[near hinge]

ye no im not touching that

i try to type whereever throw is possible

i will add levels to strictness

[worldly coral]

So, read about it with that in mind, that's what not to do. I think the problem with checked errors is that you have to handle the error immediately, i.e. rethrow if you want. And that's laborious.

[worldly coral]

The Error / Exception thing isn't bad. For example if the machine runs out of memory, you probably aren't trying to catch that error and retry. You just want to crash.

most of the time

[near hinge]

yeah

perhaps i can solve it via a class you need to use for that / extend from that?

[worldly coral]

Errors are things you can handle, Exceptions are not.

Yes they use class inheretance to distinguish

trouble is, we don't have control over what various functions throw

[worldly coral]

https://www.manishsanger.com/wp-content/uploads/2018/03/Exception-Hierarchy.png

I think I got the terminology backwards

[near hinge]

no ts got it wrong

[worldly coral]

?

That is Java in the image

[near hinge]

i know

js*

js got it wrong*

[jade yacht]

Every language except Java got it wrong?

[near hinge]

oh

wait

is it supposed to be the other way around?

[near hinge]

also you dont happen to know about how to write ts plugins, do you?

and how they work?

[jade yacht]

Nope

[near hinge]

sadge

[jade yacht]

TS doesn't have plugins

[near hinge]

it does

[worldly coral]

https://github.com/orta/TypeScript-TSServer-Plugin-Template

"Language Service Plugin" <- whatever that is

[worldly coral]

`Plugins -
plugins
List of language service plugins to run inside the editor.

Language service plugins are a way to provide additional information to a user based on existing TypeScript files. They can enhance existing messages between TypeScript and an editor, or to provide their own error messages.

For example:

ts-sql-plugin — Adds SQL linting with a template strings SQL builder.
typescript-styled-plugin — Provides CSS linting inside template strings .
typescript-eslint-language-service — Provides eslint error messaging and fix-its inside the compiler’s output.
ts-graphql-plugin — Provides validation and auto-completion inside GraphQL query template strings.`

Feels like that would only apply in the editor, but not during compilation.

[jade yacht]

Yeah, you can write language service plugins for displaying custom sorts of errors in the editor. That's the "language service".

[worldly coral]

Any clue on whether you could implement tracking of throwing functions in that way?

Like is it limited in what you can do somehow?

[jade yacht]

But you can't really extend the language itself, so whatever mechanism you did would probably require there to be no new syntax.

[worldly coral]

Ah

[jade yacht]

I'm not 100% sure it's impossible, you might be able to write basically a superset of TS and a language plugin that transpiles that superset to "real" TS under the hood and then maps errors back to the original code.

[near hinge]

oh no, im not going that way

i will simply extend the error class

and people iwll import it from my plugin

import Exception from plugin

and then use that

[worldly coral]

huh

[near hinge]

and then in the ts type checker i check if its imported from my package

I dont plan to add new keywords

[worldly coral]

So this will only show functions from your package that can throw?

[near hinge]

yeah, in the beginning

[worldly coral]

But why don't you just not use throw in your own work?

[near hinge]

I just want to do this as a general thing

i think other people would like it as well

for json.parse etc later on

[worldly coral]

I don't get it all

[jade yacht]

Despite that basically literally everyone you've talked to here has said it's not a good idea?

[near hinge]

i still believe some people would like it

[jade yacht]

It's a controversial feature in Java and Java has fewer issues than a TS version would have

[near hinge]

i get that, but i rather have annoying way of writing my app then have it crash in prod if i have many clients

i doubt most ppl in smaller projects would use it

but if you work with multiple people this can be really usefull

[jade yacht]

Like a ton of people have said, if you don't mind writing your app differently, don't use exceptions

[worldly coral]

Improved handling of exceptions in TS in general would be good. But I think that's a much bigger project than you will complete most like (in a sense that it takes serious commitment), and there's the very big issues of convincing the TS maintainers to accept it.

For your app/lib, just don't use exceptions.

It's very common. Rust, Go and Scala (good langauges) all don't use exceptions

[near hinge]

they use return values as errors

[worldly coral]

From what I've heard google have a policy of not using exceptions in C++

yep

[near hinge]

lemme ask a bit around

[jade yacht]

#ts-discussion message

[near hinge]

oh no im aware of that, but im not skilled enough to make a official proposal

[jade yacht]

Yeah, I don't think you should

[near hinge]

im nowhere near skilled enough to do something like that yet

[jade yacht]

Can't change how JS works

[worldly coral]

Does this mean ask people you work with / ask people who use your libs what they prefer? Just clarifying.

[near hinge]

ask generally around, I mean for me i dont care if i use class.tryCreate or throw

[worldly coral]

We can return tuples

[near hinge]

but i think its a thing we should have in general

[worldly coral]

return [new Error('err'), 'foo']

[near hinge]

thats an le array

[jade yacht]

Not if you call it a tuple.

[worldly coral]

LOL

[near hinge]

i know we can return that, deconstruct

[worldly coral]

A tuple refers to an array of set size and shape

[near hinge]

and have a value and a error val

and both are either null or a value

[near hinge]

ye ye

[worldly coral]

so I'm confused why we need multiple return, which is basically just tuples

[near hinge]

performance

[worldly coral]

negligible

[jade yacht]

And again, can't change JS

JS does not have multiple returns.

[worldly coral]

Well, can, they are talking about a TC39 proposal

But, really should not.

[jade yacht]

Oh, read that as "TS proposal" I see it's TC... but yeah, don't think that's happening either.

[near hinge]

ye

but people from the prime community and theos community would actually like more info on what can throw

gimme a moment, lemme find a short

[jade yacht]

Ehh

Here's Anders, a desginer on both C# and TS talking about the problems with checked exceptions: https://www.artima.com/articles/the-trouble-with-checked-exceptions

[worldly coral]

As said, there are good reasons to have more info on what can throw. What there is not a great reason for is to implement a lib that throws, then have to make some plugin to provide info IMO. If you want to you can, but it's much easier to use a return value approach in your own code.

The desire for help with existing code that throws is real, but that's a much bigger issue.

[lofty gulch]

anyways, pretty sure most if not all built-in stuff can throw
(
conversions/primitive constructors - toString/valueOf/@@toPrimitive can be customized
methods - old versions or overwrite
properties - overwrite
)
maybe just not arbitrary constructors

also anything that isn't writable

idk how much stuff isn't writable tho tbh

but having stuff like Number(x) be able to throw seems like an obstacle

[worldly coral]

When does Number(x) throw?

[near hinge]

i hate my life

[worldly coral]

why?

Did you want NaN?

[near hinge]

kind of

[worldly coral]

Number("")

[near hinge]

i know that that gives 0

[worldly coral]

At least it is consistently wrong

[near hinge]

heh

[lofty gulch]

when valueOf/@@toPrimitive throw

[near hinge]

@worldly coral i think what i would do is just mark a function with info that it can throw (via an info) and bubble up info that it can throw, this way it still gives a subtle visual hint

[worldly coral]

You've gone too deep in the JS for me haha

[lofty gulch]

also, every function can throw with a stackoverflow, but i think that's solidly in the space where you don't care

[worldly coral]

yeah

[lofty gulch]

it's basically toString but for other types

[jade yacht]

Is this meaningfully different than JSDoc comments?

/** @throws NullPointerException */
function foo() {
  throw new NullPointerException(); // I heard you like java
}

[near hinge]

i should perhaps clarify thah this is tough as a supportive tool, I dont expect people to only rely on it

[worldly coral]

I mean if we just had the ability to explicitly declare what a function throws, without any effort to cover everything, that would be nice

For example Prisma throws errors. With some type annotations we could have info on those common throws.

[near hinge]

exactly, thats the idea for ver 1

[worldly coral]

on a unique constraint violation for example, really bugs me having to catch and process those errors

[near hinge]

and probably towards the endgame the default setting and level 0 of checks

[worldly coral]

I should probably look into this more.

[near hinge]

also if you dont handle a error in a function it would mark that function as possible throw as well, so you can have a centralized handler later on

[lofty gulch]

another thing to consider is that there are some errors you don't want to handle

if you have something that interfaces with something else and that something else fails, you may want to just exit asap

unless you have other external stuff you have to free or close, that wouldn't be cleared on process termination, you wouldn't really need or want to catch in cases like that

and that "something else" could just be the web or the file system

(that's the distinction between exceptions and errors in java)

[near hinge]

https://www.youtube.com/shorts/_YV3NM3i_IY

[near hinge]

noted it

i will also add something like that to my package

https://github.com/bdsqqq/try

[jade yacht]

"I want errors as values"? Sounds like they're arguing for returning errors as values not exceptions

[near hinge]

true

anyways ima still do this

and see how it feels

[jade yacht]

Yeah, have fun

[worldly coral]

Yep, he is very Rusty

[jade yacht]

Yeah, he's a trendy tech youtuber, of course he's rusty

[worldly coral]

Seems cool, but you still don't have type info of the errors, right?

[worldly coral]

True

[near hinge]

with my plugin i think i would be able to make a module which has the actual errors

[worldly coral]

I have nothing more to say 🙂

[calm creek]

Primeagen is a content creator, I wouldn't take what they say too seriously.

They especially have a thing for hating on JS/TS, there was this one instance where they didn't know about the difference between readonly vs Readonly<T> in TS and proceeded to laugh at TS, chat had to correct them but they didn't acknowledge it. Which is very baffling because clearly they have lots of experience working with JS/TS, yet this is such an entry level knowledge.

[near hinge]

A small update: I have a running ts plugin, which can find throws and emit erros into a terminal on use, I am working right now on marking the parent method that it can throw and then adding a info in the diagnostics

[near hinge]

@calm creek @worldly coral @jade yacht IT can throw

doing progress

[worldly coral]

Nice

A little impressed to be honest

[near hinge]

wait a sec, I am murdering the quick info panel

I may be stupid

@worldly coral next step is to detect if a catch is in the way or not

but how do i get that error to the next line

\n king

[lofty gulch]

may i suggest "throws" for that, as java or jsdoc do

[near hinge]

good idea, will do

this is just the barebone mvp

@lofty gulch a question is also how do i show a list of multiple throws

[lofty gulch]

just to make sure we're on the same page, by that do you mean you want to specify what kinds of errors each function can throw?

[near hinge]

tsdoc way

[near hinge]

yep

_imagine you have an throw handler function and the jsdoc is 10 pages long

[lofty gulch]

wouldn't you just have a list

[near hinge]

probably

so like in the screenshot?

[lofty gulch]

well jsdoc hover just shows all the tags indiscriminantly

[near hinge]

can you mock test it for me?

[lofty gulch]

i don't think i can dedicate time for that right now, im pretty busy, sorry
(if i accept i will not get any actual work done in the next 2-3 days)

[worldly coral]

I'd display it as a union if possible

throws string | number | object

with the throws a different color to the type

Although I don't know that you can correct condense down unions with overlap at that level.

[near hinge]

no worries

[near hinge]

I actually want to make them clickable

but i dont know how i would do that

imagine you click it and jump to the throw

[lofty gulch]

sounds like you could utilize codelens

[near hinge]

that would be dope

[worldly coral]

hmm

[near hinge]

actually for that it has to be a vscode plugin, does it not?

[lofty gulch]

yeah

[worldly coral]

you might have a lot of duplication.

[near hinge]

can filter them out later

for now that frankensteinsshite should just run

[worldly coral]

Does it display if a function's inner function throws?

[near hinge]

and oh god, the code cleanup later on

[near hinge]

will later on, yes

[lofty gulch]

although would probably have to be in the vein of "show references" rather than "go to definition" since there could be multiple throws

[worldly coral]

OK

[near hinge]

true, but i also show the type instead of the throw

i think thats smarter

or what should i do

[lofty gulch]

also, how do you plan on treating TypeErrors and such from language or library stuff?

[near hinge]

either jsdoc, or for now not at all

[lofty gulch]

you could have multiple throws with partially overlapping unions though

[lofty gulch]

so the exception vs error route

[near hinge]

ahh, it will be always just a subtle hint

you can ignore it if its an exception

or i will later add my custom Exception class

which would disable that check

[lofty gulch]

errr that's not what i mean

[near hinge]

btw do you know a plugin expert i can ask a difficult question?

[lofty gulch]

i mean just separation in design, not in code
how i understand it is:
throws are like exceptions, known and shown
stuff like null property access or spread with no iterator are like errors, issues that could happen anywhere and you don't particularly want to handle

[lofty gulch]

https://dontasktoask.com

[near hinge]

ahh, for now i just show user defined errors, I will not cover the entire of js, since its near impossible

[near hinge]

I need to figure out how to override the type in a try catch error

[worldly coral]

Ah, tame.

[lofty gulch]

couldn't you just ignore everything inside the try

[near hinge]

no i will do that, the reason why i want to do that is it would be really awesome to have typed catch

dont you agree?

[lofty gulch]

oh you mean the catch variable, i misunderstood

[near hinge]

it would be a union + unknown

yeah

[calm creek]

Are you saying catch (error) where error should get strongly typed rather than unknown? I would not suggest it since your plugin is not capable of analyzing native and foreign code that throws.

[lofty gulch]

that would just be unknown

[calm creek]

T | unknown is just unknown.

[near hinge]

really? if you use a if condition, would it still not give like help?

[calm creek]

Nope, it's like 42 | number is just number.

[near hinge]

O:

:c

i guess i can add a tooltip above it

:c

[calm creek]

unknown is the top type.

[lofty gulch]

if it's | unknown, then a condition specific to the union wouldn't mean anything since it could be something else

[near hinge]

my idea was for ide auto complete if you do a chain of if statements to check for the error type

ye autocomplete not working :C

now im sad sad

[lofty gulch]

unknown is analogous to the universe set 𝑈, for any set 𝐴, 𝐴 ∪ 𝑈 = 𝑈

[near hinge]

no i understand that

what i was reffering to that the ide still works with what he knows, but allows for the rest

like known key values in a dynamic dictionary

[jade yacht]

Technically there's a workaround for the string case, but I don't know what kind of 'autocomplete' you would get from a SpecificError | unknown union anyway.

[lofty gulch]

(∀𝐴⊂𝑈[𝐴 ∪ 𝑈 = 𝑈])

[lofty gulch]

maybe a snippet?

[near hinge]

OH, so it recommends a snippet?

but thats a vscode plugin again

[calm creek]

You can offer a code action.

[lofty gulch]

well, you're talking about stuff that would go through the ide...

[near hinge]

true dat

hmm

perhaps, i should make the ts plugin really good, but then make a extension based on it and do those advanced tools as well

[calm creek]

^

[near hinge]

wait wha

OMG

u smart

[lofty gulch]

wouldn't that also be via an ide plugin

[calm creek]

Code action is a LSP thing, any IDE supports LSP can make use of it.

[near hinge]

yeah

i had gpt tell me that

i forgot about that

Completion details

maybe

i can actually do it

even if its an unknown type

it shows as unknown but type helper still work

[lofty gulch]

code action via tsc plugin seems a bit of a roundabout way to do it

is that even possible?

[near hinge]

it is

code fixed => refactoring

i can make a recommendation to refactor catch() to a catch with all if statements

that would be so good

@lofty gulch imagine you have a function which can error, you go to the catch, press a button, and boom, you have a list of all possible recorded throws and a catch all final one

[lofty gulch]

through tsc?

[near hinge]

yes

only question, do i use if else or switch statement?

@calm creek do you want me to immortilize you in the src code?

[lofty gulch]

how would you do a switch

kinda need an if for this

[near hinge]

switch (err) {
case condition:
break
}

cant you do instance off etc all with switch?

[lofty gulch]

no

switch (x) {
  case y:
}
```is analogous to```ts
if (x === y) {

}

the === is locked in

[calm creek]

Eh, I don't really care either way, it's not that big of an insight either.

You can do the (imo ugly) switch (true).

[lofty gulch]

oh yeah, that's a thing

i don't think that would be good as a recommendation tho

[calm creek]

Maybe in 10 more years JS will finally get pattern matching.

[near hinge]

isnt that in stage 2 or 3

https://github.com/tc39/proposal-pattern-matching

stage 1

[lofty gulch]

you would need a switch (true) at the top and it doesn't really provide any real benefit over a if chain with much less readable conditions

[near hinge]

ye, lets go with if else