chore: handle error returned from resolve_data_source()

[xudong963]

I hereby agree to the terms of the CLA available at: https://docs.databend.com/dev/policies/cla/

Summary

handle error returned from resolve_data_source()

Fixes #14070

Tests

• Unit Test
• Logic Test
• Benchmark Test
• No Test - covered by current codebase

Type of change

• Bug Fix (non-breaking change which fixes an issue)
• New Feature (non-breaking change which adds functionality)
• Breaking Change (fix or feature that could cause existing functionality not to work as expected)
• Documentation Update
• Refactoring
• Performance Improvement
• Other (please describe): improve error handling

---

This change is 

[drmingdrmer]

Reviewed 1 of 2 files at r2, all commit messages.
Reviewable status: 1 of 3 files reviewed, 3 unresolved discussions (waiting on @BohuTANG, @lichuang, and @xudong963)

---

src/query/sharing/src/share_endpoint.rs line 150 at r2 (raw file):

                        share_name, e
                    ))),
                }

A json decoding error should be considered as internal error IMHO. UnknownXXX should be used only when an object does not exist, not when an object is damaged.

---

src/query/sql/src/planner/binder/table.rs line 263 at r2 (raw file):

                    parent = bind_context.parent.as_mut();
                }
                if e.code() == 1025 {

Use named const ErrorCode::UNKNOWN_TABLE instead of integer.

Does it need to deal with other causing errors such as UnknownDatabase? There are several other errors needs to be considered: WrongShare, WrongShareObject, UnknownTableId

[xudong963]

A json decoding error should be considered as internal error IMHO. UnknownXXX should be used only when an object does not exist, not when an object is damaged.

cc @lichuang, how about opening a new PR to process here?

[xudong963]

@lichuang will open a new PR