Can plugin error messages be less verbose?

[kevin4]

I’ve written a plugin that outputs a list of links for a specified URL.

This question is about error handling.

When I enter a URL that generates a 404 error, I get a very verbose error message.

I know from experimentation that axios (the node module I’m using to get the URL) generates only a tiny bit of it.

So the rest must be generated by Bubble.

My question is, is there anyway to suppress the verbosity and ONLY capture the value of error.message when axios.get(url) throws an error?

Specifically, in the verbose message below:

Plugin action getLinks error:
AxiosError: Request failed with status code 404
at settle (/var/task/node_modules/axios/dist/node/axios.cjs:1859:12)
at Unzip.handleStreamEnd (/var/task/node_modules/axios/dist/node/axios.cjs:2723:11)
at Unzip.emit (events.js:412:35)
at endReadableNT (internal/streams/readable.js:1333:12)
at processTicksAndRejections (internal/process/task_queues.js:82:21)

Error: Outer Error (see above for inner error)
at Block.wait (/var/task/u.js:467:22)
at Object.async_fn [as async] (/var/task/index.js:474:29)
at eval (eval at build_function (/var/task/index.js:53:12), :33:34)
at /var/task/index.js:527:17
at run_fn (/var/task/u.js:645:18)

The part returned in error.message is “Request failed with status code 404”.

That’s the only bit I want to be displayed in the error popup shown to the user.

Does anyone know if this can be done? And if so, how?

[doug.burden]

Yea. If you’re writing your own logic and you know an error might throw somewhere just do the ol

throw new Error(“Aye big dawg somethin’ wrong here”);

[kevin4]

In my plugin I can’t know an error will be thrown, I can only know that one has been.

The statement that succeeds or throws an error is:

let response = await axios.get(url)

Either the page loads into the variable, or an error is thrown.

[dorilama]

try/catch it and call the context.async callback with your own error

[kevin4]

I already do the callback with the preferred error message, which is in fact err.message. But I don’t know how to suppress all the OTHER text.

Below is the existing context.sync try/catch code.

    let returnedObject = context.async(async callback => {
        try {
            let response = await axios.get(webpage)
            objectToReturn._p_returnStatus = response.status
            objectToReturn._p_returnStatusText = response.statusText
            console.log("CustomPlugin:getLinks:objectToReturn:try1: ", objectToReturn)

            const $=cheerio.load(response.data)
            const webpagelinks = $("a")
            console.log("CustomPlugin:getLinks:webpagelinks: ", webpagelinks)

            webpagelinks.each(function () {
                var link = {
                    "href": $(this).attr('href'),
                    "rel": $(this).attr('rel'),
                    "text": $(this).text()
                }
                objectToReturn._p_links.push(link)
            })
            console.log("CustomPlugin:getLinks:objectToReturn:try2: ", objectToReturn)
            objectToReturn._p_links.shift()
            console.log("CustomPlugin:getLinks:objectToReturn:try3: ", objectToReturn)
            objectToReturn._p_stringified = JSON.stringify(objectToReturn)
            console.log("CustomPlugin:getLinks:objectToReturn:try4: ", objectToReturn)

            callback(null, objectToReturn)
        }
        catch (err) {
                callback(err.message)
        }

    })

[dorilama]

you may use the other error properties if it’s more convenient for you.
Or you can add logic to analyse the error and return your custom error with the callback.

[kevin4]

That’s an interesting idea. I’ll experiment with that. Thank you.

[dorilama]

Also this may help you directly with the part you find annoying (it’s pinned on v14 because that’s what you get currently for ssa)

[kevin4]

Well, it was a nice thought while it lasted.

To test the idea, I changed my catch code to this.

        catch (err) {
            let errorMessage = "Test custom error message"
            callback(errorMessage)
        }

And it returned the test custom error message, among all the verbosity.

I have no idea if I can throw an error in the catch section of the code, but I’ll run an experiment. It feels to me right now that that will be too late to suppress the verbosity, but we’ll see.

[dorilama]

have you tried calling the callback with the whole error instead of the message? This way you should have other properties of the error available in the editor. As I said message is just one property

[doug.burden]

you’ll have to use throw new Error(“Something aint right cuzz”);

Or in your case throw new Error(errorMessage);

[kevin4]

I have.

[kevin4]

This may work.

When I throw an error in the catch part of the code, the callback is never executed.

However, when I execute:

        catch (err) {
            throw err
            callback(err)
        }

I see a verbose alert, but a less verbose alert:

But when I:

        catch (err) {
            throw err.message
            callback(err)
        }

I do not see any alert.

So I’ve got some experiments to run, but you guys have been a great help.

Thank you,

[dorilama]

throwing inside a catch inside context.async it’s probably a bad idea.
Let us know if you find something useful

[kevin4]

I’m investigating if I can nest catches.

Something like:
catch (error)
throw myError
catch (myError)

I’ll let you know if this works.

[kevin4]

No joy.

Nested try/catch structures work in Node JS:

    catch (error1) {             /* https://www.npmjs.com/package/axios#handling-errors */
        console.log("CustomPlugin:getLinks:catch:error1.response.status: ", error1.response.status)
        console.log("CustomPlugin:getLinks:catch:error1.response.statusText: ", error1.response.statusText)
        console.log("CustomPlugin:getLinks:error1.message: ", error1.message)
        try {
            console.log("CustomPlugin:getLinks:try2:error1.message", error1.message)
            throw error1.message
        }
        catch (error2){
            console.log("CustomPlugin:getLinks:catch:error2: ", error2)
            objectToReturn._p_returnStatus = error1.response.status
            objectToReturn._p_returnStatusText = error1.response.statusText
            console.log("CustomPlugin:getLink:.catch1: ", objectToReturn)
            objectToReturn._p_links.shift()
            console.log("CustomPlugin:getLink:.catch2: ", objectToReturn)
        }
    }

But in context.async, they generate the same verbose error as before.

        catch (error1) {
            console.log("CustomPlugin:getLinks:catch:error1.message: ", error1.message)
            try {
                throw error1.message
            }
            catch (error2) {
                callback(error2)
            }
        }

I think I’ll throw in the towel on this and go for the least verbose option from earlier.

[AliFarahat]

I noticed that error messages for you as a developer of the plugin while in testing are different in the error messages when the plugin is installed

Also I believe there’s a built-in function to report the error to the debugger

Might be worth a look

[keith]

Not to be cryptic, but context.async is garbage. There’s no need for it and it only works once. Do things differently.

[doug.burden]

How would you do it?

[dorilama]

again: why are you still using error.messageif you don’t like it?
There is a clear example at the axios’ docs about handling errors. No nested try/catch needed, every error is handled, other properties of the error are used to give more context.
Of course you need to replace log statements with callback calls.