chore(async): {.async: (raises).} for connmanager
#1172
Conversation
lchenut
changed the title
{.async: (raises).} for connmanager{.async: (raises).} for connmanager
| @@ -67,7 +67,8 @@ type | |||
| muxed: Table[PeerId, seq[Muxer]] | |||
| connEvents: array[ConnEventKind, OrderedSet[ConnEventHandler]] | |||
| peerEvents: array[PeerEventKind, OrderedSet[PeerEventHandler]] | |||
| expectedConnectionsOverLimit*: Table[(PeerId, Direction), Future[Muxer]] | |||
| expectedConnectionsOverLimit*: | |||
| Table[(PeerId, Direction), Future[Muxer].Raising([CancelledError])] | |||
There was a problem hiding this comment.
What would be the difference between this and using a Future[Result[Muxer, ...]].
Actually, I guess the broader question would be: Is there a reason we're going for exceptions over handling errors with Result?
There was a problem hiding this comment.
I'm not an expert, but Nim natively supports exceptions and there's also compiler support for pros signatures https://nim-lang.org/docs/tut2.html#exceptions-annotating-procs-with-raised-exceptions. Resultwas created in some status library. It might be painful to use Resultif Nim std wasn't designed for that. I can't say much as in general, this project uses more exceptions than Result.
| ## Acquire a resource and decrement the resource | ||
| ## counter. If no more resources are available, | ||
| ## the returned future will not complete until | ||
| ## the resource count goes above 0. | ||
| ## | ||
|
|
||
| let fut = newFuture[void]("AsyncSemaphore.acquire") | ||
| let fut = Future[void].Raising([CancelledError]).init("AsyncSemaphore.acquire") |
There was a problem hiding this comment.
we can create a new template in utils/future.nim:
template newFuture*[T](fromProc: static[string] = ""): auto =
Future[T].Raising([CancelledError]).init(fromProc)
Add
{.async: (raises).}to connmanager.nim and to semaphore.nim (which is needed by connmanager.nim)