Better handling of list of IDs when there are more than 50
artyuum opened this issue ยท 8 comments
I found out that when providing more than 50 tracks, the other tracks will be silently ignored:
spotify-dart/lib/src/endpoints/tracks.dart
Lines 77 to 81 in f86276b
Maybe it would be better if we throw an error instead? WDYT?
@artyuum Something like:
Future<void> save(List<String> ids) async {
assert(ids.isNotEmpty, 'No track ids were provided');
assert(ids.length <= 50, 'Track id length exceeded');
// ...
}
?
Doesn't assert()
only work in development? This means once compiled these asserts will be disabled ๐ค
I'm not familiar with the Dart language but I read it here: https://dart.dev/language/error-handling#assert
I would keep this check every time, no matter the env, and I would also explicitly tell about this limit of 50 in the error message so the dev knows exactly why this error happened.
oh okay, I didn't know about this. This also means, that all the other assert
s are practically useless, once the library is compiled.
@rinukkusu I wonder now, what the use cases of the assert
statements might be if they are ignored. Is it only for debug purposes?
Plus, if we throw exceptions e.g. for empty ids
or exceeded ids
-length, the users of this library then have to catch them. This would indicate "breaking changes" in the library, which imho I would avoid.
Having this in mind, I would suggest to return a Future.error()
with some ArgumentError
s (or we create our own). So something like
Future<void> save(List<String> ids) async {
if (ids.isEmpty) {
return Future.error(ArgumentError('No track ids were provided'));
}
if (ids.length > 50) {
return Future.error(ArgumentError('Number of track ids exceeds limit of 50'));
}
// ...
}
@rinukkusu what do you think?
This would indicate "breaking changes" in the library, which imho I would avoid.
No need to completely avoid it. Such change can be done in a new major version (v1).
@rinukkusu I wonder now, what the use cases of the
assert
statements might be if they are ignored. Is it only for debug purposes?
@hayribakici I don't really remember - I think this is something that got introduced by other collaborators like yourself. ๐ค
Having this in mind, I would suggest to return a
Future.error()
with someArgumentError
s (or we create our own). So something like
@hayribakici from what I could gather, it looks like returning Future.error(...)
and throwing exceptions behave the same. Both can be caught with a try-catch block or in the .catchError(...)
method of the Future
. That's why I'd vouch for throwing exception objects like ArgumentError
directly instead of returning Future.error(...)
. A little less fluff.
I don't think it's that breaking anyway, since if we don't "protect" from it, in most cases we'll just get an HTTP error then from the Spotify API, if not undefined behavior, right?
Relevant xkcd ๐ธ
@hayribakici I don't really remember - I think this is something that got introduced by other collaborators like yourself. ๐ค
tbh, I just went with it ๐
Both can be caught with a try-catch block or in the
.catchError(...)
method of the Future. That's why I'd vouch for throwing exception objects likeArgumentError
directly instead of returningFuture.error(...)
. A little less fluff.
okay, sounds good ๐
@rinukkusu should we create a specific issue for this, that indicates all assert
statements?
@hayribakici yeah, a new issue sounds sensible. Thanks!
Closing, since we created another issue for this.