`<await-error>` calls `console.error`

runeh commented 7 years ago

Bug Report

Context

When using <await-error> to deal with rejected promises, marko calls console.error with the error. See https://github.com/marko-js/marko/blob/master/taglibs/async/await-tag.js#L111 .

For us this has two consequences:

The console.error call ends up in stdout. In our container setup we use stdout for logging, with JSON entries. The marko output confuses our log parser.
It's inconsistent to warn about an error in the case where the developer has explicitly provided an error handling tag.

Expected Behavior

<await-error> tag does not cause console.error to be called.

Actual Behavior

<await-error> tag does causes console.error to be called.

Possible Fix

Having this logging can be useful during dev. Maybe ut could be behind a flag or something, so you can pass silent-error=true to the <await> tag or similar?

Your Environment

Version used: 4.1.2
Environment name and version: node v6.6.0

Steps to Reproduce

Load the code from https://gist.github.com/runeh/7adf1873b45ffa9d0b6723da4e410f4c into http://markojs.com/try-online/
Look at output in error console

patrick-steele-idem commented 7 years ago

Putting the logging behind a flag/attribute is definitely an option and I am not opposed to that. However, if you need that level of control, I would recommend not using the <await-error> tag and, instead, make sure there the promise is not rejected by providing your own .catch(). For example:

$ var userInfoPromise = getUserInfo()
    .catch((err) => {
        return {
            error: err
        }
    });

<await(userInfo from userInfoPromise)>
    <if(userInfo.error)>
        We are sorry, we were unable to retrieve the user information.
    </if>
    <else>
        Hello ${userInfo.firstName}!
    </else>
</await>

Thoughts?

runeh commented 7 years ago

I ended up changing our code to deal the promise rejection in the renderer. But that seems unidiomatic, given that there are tags meant for dealing with timeouts and errors inside of await?

Anyway, it still feels counter-intuitive to me that there is console.error output in a case where I've explicitly added code to deal with the error. I would prefer it not logging on my behalf in that case.