Remove the "catch" statement from samples included in CKEditor 5 builds (?)

[wwalc]

I recently encountered an issue when trying to load one of 3rd party plugins into a CKEditor 5 build. Unfortunately the error logged in the console was completely useless:

Only after I commented the catch block, it showed me something meaningful:

It took me a few seconds to understand that I can try getting rid of the catch statement that looked like something that should just show me the correct stack trace, to see if that changes anything:

In order to improve the developer experience, I'd get rid of that statement.

[Reinmar]

That's a good catch. We could remove the catch() calls but:

1. we'd have to check that an unhandled promise error is logged to the console on all browsers (I think it wasn't true back in the days),
2. it's a good practice to have the .catch() call at the end of a promise chain, so I'm not sure how lack of it will be seen by the developers – it'd be good how others do that in their docs.

[jodator]

2\. it's a good practice to have the `.catch()` call at the end of a promise chain, so I'm not sure how lack of it will be seen by the developers

Well to be honest I don't what's worse dummy catch or no .catch() clause at all ;)

Maybe the better solution would be (ps.: remember about the full names, like in error?):

.catch( error => {
    // Handle the editor initalisation errors - ... (or some better text :P )
    console.error( 'There was a problem with initializing the editor', error );
} );

with the above we have: full error logged, no uncaught error in promise logged and better practice with having he catch() clause.

But logging the full error will be better then logging only err.stack.

[Reinmar]

But logging the full error will be better then logging only err.stack.

That's the point of:

2. it's a good practice to have the .catch() call at the end of a promise chain, so I'm not sure how lack of it will be seen by the developers

It doesn't work now, but perhaps it can work. The flaws of the current body of the catch() callback are (perhaps) not a reason to completely negate the value of using that catch(). Let's just find out if there's a better way.

[jodator]

Let's just find out if there's a better way.

Logging the full error object instead of error.stack as a start. Adding some message to this might be also helpful (to show that we caught that error).

[wwalc]

Getting rid of the catch statement was the first idea that came to my mind to solve the real problem that was introduced by "wrong" catch statement. I do agree with both of you that if we can catch errors but at the same time show the full information about the issue (log the full error, whatever) + a custom error message as proposed in #1803 (comment), then it would look more professional, then just getting rid of the catch statement.

[mlewand]

Fixed with a PR in each build:

• decoupled-document
• inline
• balloon
• classic (main)
• balloon-block