fix: line authoring crashes when dom Element cannot be removed.

[GollyTicker]

This bug has been here since the very beginning when I implemented the line authoring into obsidian-git.

For unknown reasons, somtimes the dom.remove() fails and an exception is bubbled up - which makes the line authoring and afaik the whole plugin crash. Then the line authoring suddenly disappears and can't be brought back without a restart. It's hard to consistently reproduce it and I didn't brother too much with it back then - but this simply try and catch should fix it sufficiently.

Whenever I come across this error, I have to restart obsidian - but this isn't a good workaround for users who don't know what's happening. They'll probably just abandon this plugin or whatever.

Do you have any questions?

[Vinzent03]

Do you know how the error looks like? And I think it's better to not just silently ignore the error, but at least log it to console. This should make it easier to debug or detect other issues because of this error in the future.

[GollyTicker]

I come across this error once a week of so. Essentially it says, that the dom-element can't be removed because it wasn't found anymore. We can log the error into warn if you want.

…

On Mon, Mar 31, 2025, 14:30 Vinzent ***@***.***> wrote: Do you know how the error looks like? And I think it's better to not just silently ignore the error, but at least log it to console. This should make it easier to debug or detect other issues because of this error in the future. — Reply to this email directly, view it on GitHub <#891 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABCRN5UD5HT3Z4HTCJK3NBL2XEYNPAVCNFSM6AAAAAB2CY3PAWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDONRWGA3TQNJVGM> . You are receiving this because you authored the thread.Message ID: ***@***.***> [image: Vinzent03]*Vinzent03* left a comment (Vinzent03/obsidian-git#891) <#891 (comment)> Do you know how the error looks like? And I think it's better to not just silently ignore the error, but at least log it to console. This should make it easier to debug or detect other issues because of this error in the future. — Reply to this email directly, view it on GitHub <#891 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABCRN5UD5HT3Z4HTCJK3NBL2XEYNPAVCNFSM6AAAAAB2CY3PAWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDONRWGA3TQNJVGM> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[GollyTicker]

Here is the stacktrace when an error happend.

app.js:1 TypeError: Cannot read properties of null (reading 'remove')
    at lp.destroy (plugin:obsidian-git:179:6373)
    at e.setMarkers (app.js:1:520587)
    at e.destroy (app.js:1:520791)
    at e.destroy (app.js:1:519730)
    at e.updateGutters (app.js:1:516057)
    at e.update (app.js:1:514220)
    at e.update (app.js:1:352236)
    at e.updatePlugins (app.js:1:458752)
    at e.update (app.js:1:456799)
    at e.dispatchTransactions (app.js:1:453296)
Gi @ app.js:1

[Vinzent03]

So the error is that dom is null. Isn't it better to just check if it's null or not than catching all errors? The if check is always true for a null value, so I would add that check to the existing if-clause of find the reason for dom being null.

[GollyTicker]

I added a check for null now. I'll keep the try catch and the warning, ok?

[Vinzent03]

Hmm no I would remove the try-catch and just keep the null check. I'm not aware of any reasonable errors that can happen there that should be caught. If the remove fails, it might have a good reason and should be caught higher up in the call tack.

[GollyTicker]

Changed.