ccxt: Make exceptions less noisy
In the meantime all the details of the http- and exchange- errors are included in the exception string:
def raise_error(self, exception_type, url=None, method=None, error=None, details=None):
if error:
error = str(error)
output = ' '.join([self.id] + [var for var in (url, method, error, details) if var is not None])
raise exception_type(output)
– the details here includes the http-response came from exchange…
When we handle such exception in the app, this often results in long sheets of html data, even if the logging value is less than DEBUG and the user did not requested this high level of detalization.
The suggestion is to include the value of the details param into the exception string only when the DEBUG logging level is set for ccxt.
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Reactions: 1
- Comments: 29 (29 by maintainers)
#5467
@kroitor #5494
our plan is to only set the error message in the error like
hope to get this merged by the end of the week.
angry emoji react so @kroitor merges my pr
yep this is something we are going to change - #5399
and we will move to a new
raise_errorjust waiting on @kroitor to merge my PR 😠
@hroff-1902
@frosty00 helped make significant progress in that direction, so, we’re doing great and we’re very close to resolving this issue.
Yep:
yep. agreed. all in good time 😃 CCXT is awesome, but as with all software we can always improve it
@hroff-1902
No, never. We will not do anything convenient. Forget about it. Only over @frosty00’s body.
But, seriously, yes, of course ) The default level will be quite verbose, but you will have at least a few ways of setting the verbosity, either with an exchange property/option, or with a description override, as you noted below.
This is exactly one of the purposes of the unification process that is going on, so, yes, you’re right as well. Both of you are right ) I’m sure @ahmedbodi would be happy to rely on ccxt DDoS exceptions, if they were completely unified – in that case he would not need a long description. I guess, he doesn’t like to read too much meaningless markup either )
To me there’s no arguing above at all. CCXT is not ideal because it’s a work in progress, but we will make it closer to an ideal soon. No worries, everyone will be happier.
@kroitor Will I be able (after mentioned unification) to log a less detailed exception string (say, with maximum one-string http response, without full html data) in the application if it’s unwanted (for example, if the verbosity level in the application is not set to debug)? You answered several times to @ahmedbodi above that you understand him and that his points are clear, but I did not completely got yet if you understand why I’m asking for this detalization level be controllable (or at least all the detalization be separated in a field in the exception so that we could use a less noisy exception description if we need so)…
Your point is clear from the very start, and, of course, we would never leave it like that – it’s in progress, hope for your understanding. Until it is unified you have to add workarounds in userland, that’s right. We hope to completely unify it soon.
yep, ofc. thats my point. until they are, the HTML actually is useful for many people
ideally they’d be handled in CCXT but many exchanges right now arent handled in CCXT
@ahmedbodi Is there a reason to handle the ddos exceptions in your code instead of adding them to the exchanges in ccxt?
if we update all the exchange classes to actually contain high quality exception handling then it wouldnt be needed. but until then its pretty essential