Implement TFChainError in chain client

[Mahmoud-Emad]

Changes

• Created a new Error wrapper to throw errors based on their type.
• Determined the type of error and threw it accordingly.
• Updated the error interface to differentiate between Module, Token, and other error types.
• Remove the TFChain error from the types package.

Related Issues

• Refactor error types or introduce new class  #3071
• Refactor tfchain _applyExtrinsic error handling to include other dispatch errors  #3072

Checklist

• Tests included
• Build pass
• Documentation
• Code format and docstrings
• Screenshots/Video attached (needed for UI changes)

[0oM4R]

I see we are going to move the tfchain error from the types package to the tfchain package, is there a reason for that, as we discussed before we need to only refactor the class, and for the other issue we could add a method to that class to resolve the error.

[Mahmoud-Emad]

I see we are going to move the tfchain error from the types package to the tfchain package, is there a reason for that, as we discussed before we need to only refactor the class, and for the other issue we could add a method to that class to resolve the error.

As discussed with @AhmedHanafy725 , we'll create an interface with specific fields to capture error details. We'll populate these fields based on the error type. Placing the changes in the types package makes sense yeah. Please review the changes.

[0oM4R]

Please don't use the extrinsic data, it may invalid error data #2896, it happened before and we decided to get the exact error method #2995

we can't rely on the extrinsic

[0oM4R]

thank you for the great job ya Omda

[0oM4R]

suggestion

i notice that when throwing generic error we have something like this

what i suggest :
1- set keyError default value to Generic Error
2- hide the undefined props,

we can do that by remove the class properties and if it is passed use Object.DefineProperty

class TFChainError extends Error implements ITFChainError {
  constructor(options: ITFChainError) {
    super(options.message);
    this.name = "TFChainError";
    options.keyError && Object.defineProperty(this, "keyError", options.keyError);
    options.section && Object.defineProperty(this, "section", options.section);
    options.args && Object.defineProperty(this, "args", options.args);
    options.method && Object.defineProperty(this, "method", options.method);
    options.docs && Object.defineProperty(this, "docs", options.docs);
  }
}

this will hide the undefined props:

but this have one consequenc: we won't have autcomplete and will be diffecult to access the props if it is defined, so the solution is to define an interface with the same name of the class with the optional props

interface TFChainError {
  keyError?: string;
  section?: string;
  method?: string;
  args?: AnyTuple | string[];
  docs?: string[];
}

now we will be able to access them normally

[Mahmoud-Emad]

In my honest :), it's not good to follow, why? because we have a class that implements an interface, you have to follow the interface, there are no blockers with the undefined value, make it simple ya Omar xD :P

[0oM4R]

Do you mean the 'ITFChainError'?
We can remove the optional values from the interface and follow it, anyways my suggestion is for better look only.