Yes, your understanding is correct that you need to use topic when there are multiple subscribers that want to consume the same message.
Individual subscriber will be consuming the messages from the individual subscription of the same topic. Subscribers can define which messages they want to receive from a topic using the filter.
When there is an exception generated at the application you can refer to different exception types that will help you to understand cause, and notes suggested action you can take. Let's say if your consumer application has peaked the messages but was not able to call Compete on that messages due to any reasons (application crash, server restarted, etc.) then once the lock expires (after lock duration) on that message then the message will be again visible for your consumer to be consumed. The brokered message delivery count property will keep on increasing for that message for every failure your client application is not able to consume that message. Once it has reached the MaxDeliveryCount the message will be deleted (if you have disabled dead lettering property of subscription) or moved to dead letter queue.
You can update the MaxDeliveryCount property (default value 10) to your own value according to your requirement and use service bus metrics (Dead -letterd messages) to setup the alter to notify you if there is any message in the dead letter queue.
Azure service bus SDK already has a default retry mechanism and you can refer to this article for more details.
Note: You need to refer to expectation type to understand in which exception the inbuild retry works. If the "inbuild retry doesn't help" then you need to implement your own retry logic to retry that operation. When there is a client issue/error/code issue from client side the inbuild retry doesn't help.
Hope the above helps and please let me know if you have any queries.
Please 'Accept as answer' and ‘Upvote’ if it helped so that it can help others in the community looking for help on similar topics.