#fetch not throwing consistently

1 messages · Page 1 of 1 (latest)

stable quartz
lilac comet
#

Thanks for creating a thread about this I guess

stable quartz
#

you mean you are providing the same target id twice and it has different behaviour?

#

aka: 2. should not happen?

lilac comet
stable quartz
#

what do you mean it gives you two outputs?

#

that entire line will return a Promise instance, where do you get a second one?

lilac comet
#

Let me put the second one in a ".then" to be sure

stable quartz
#

can you show more of the code this is embdedded in?

lilac comet
#

Alright, I'll do my best to cut it down so you can still see the relevant parts

lilac comet
# 
First time: 

DiscordAPIError: Unknown Ban





Output
959877483526758451

Is the console output for this run

#

Output = Second time, I changed the name in my code

stable quartz
#

regarding line 25ff.

which is useful to accomplish new actions even after an action failed in the chain

lilac comet
#

Give me a mo

lilac comet
#

If you don't mind, please send your answers to my DMs or ping me so I can see it when I come back. I'll be on my phone/tablet but not at my pc.

stable quartz
#

ah, i see

stable quartz
#

i think what you are seeing here is the return value of the catch

#

not too sure why that's just an id, though

lilac comet
#

In line 35

stable quartz
#

that is a message object? that's expected

#

because that's the return value of the #editReply call

lilac comet
stable quartz
#

you return a value from the scope of the catch callback

#

which is what the promise resolves with

#

which is then also passed to the .then() you chain to the.catch()

#

-ev new Promise((res, rej) => rej(3)).catch(() => 4)

split cloudBOT
stable quartz
#

-ev new Promise((res, rej) => rej(3)).catch(() => 4).then(resolved => resolved)

split cloudBOT
lilac comet
stable quartz
lilac comet
stable quartz
#

any code you want to execute after the successful completion of the promise has to be within a then callback that is chained before a catch

#

you return #editReply in both 29 and 32 - which are both possible control branches

#

that is what tempbanfetch resolves with

#

and accordingly also what it's value is like 35 ff.

# 
const ban = await bans.fetch(id).then(ban => {
  // everything that depends on the ban being fetched successfully
  return 1 // what you want "ban" to be in case of success
}).catch(err => {
  // everything that needs to happen if the ban fetching was rejected (error handling)
  return 0 // what you want "ban" to be in case of the rejection
})
// ban can now be 1 or 0
# 
const ban = await bans.fetch(id).catch(err => {
  // everything that needs to happen if the ban fetching was rejected (error handling)
  return 0 // what you want "ban" to be in case of the rejection
})
// ban can now be a ban (what the promise resolves with in case of success) or 0
#

the code will continue in either case with the respective value the promise will resolve with

lilac comet
stable quartz
#

having all code that requires the successful completion in a single then
or - which i personally prefer - just wrapping the entire scope in a try {} catch {} block

#

@lilac comet something like

try {
  const ban = await fetchBan();
  await unban(ban.user.id);
  await send("successful unban");
} catch (e) {
  logger.error(e);
  await send("oop").catch(() => {}) // try to inform that something wrent wrong, ignore if that doesn't work either
}

seems to be much more to the point and easier to wrap one's head around for your use case

#

if you want more granularity as to what rejected

try {
  const ban = await fetchBan();
  try {
    await unban(ban.user.id);
  } catch {
    await send("couldn't unban");
    return; // returns from the entire surrounding function scope, stops execution
  }
  await send("successful unban");
} catch (e) {
  logger.error(e);
  await send("oop").catch(() => {}) // try to inform that something wrent wrong, ignore if that doesn't work either
}

or similar would of course also make sense

  • though at that point i'd probably wrap it into functions. at a certain level try-catch-trees become quite the eyesore and semantical error magnet
lilac comet
stable quartz
#

well, they both "end" in their own way, right
if you put code outside the catch {} it still keeps executing

#

the complication is the return values resolving into each other and propagating the value to the assignment

#

as well as return returning from the function scope

#

.catch(fn) fn has it's own function scope, returning from it will not return the outer scope ~ "end" execution

lilac comet
stable quartz
#

@lilac cometnot that i know of (since js has no pointers, wouldn't know how to)
i think you'd need to exploit the property of returning something different and then returning the outer scope

const res = await fetchBan().catch(() => 0)
if (!res) { // ban would be truthy, 0 is falsy (just to stick with the 0 from the example before)
  return; // return from the outer scope, if falsy return val
}
// do something with res
lilac comet
#

If you don’t mind I’d like to keep this open to note something and then let it archive afterwards

stable quartz
#

sure, it's set to 1h? if you need more i can extend

lilac comet
stable quartz
#

24h inactivity set firY

lilac comet
#

Thank you so much 😊

stable quartz
#

no problem, have fun with your project firH

lilac comet
#

@stable quartz Sorry for the ping but how did you get to your discord username? It reminds me of a movie to be honest

stable quartz
#

Soujiro turned into Souji as a nick