These are chat archives for dennisdoomen/CSharpGuidelines

Oct 2018
Dennis Doomen
Oct 17 2018 12:25 UTC
I don't agree with that mantra
What I mean is that I don't like to use return values for methods that are not supposed to fail.
If they can fail under normal circumstances, I would make that explicit in the name of the method.
Or by providing a property to see if calling that method is save to be called
E.g. Save and CanSave
Kris Kater
Oct 17 2018 15:03 UTC
Thanks for the reply. We are having a recurring discussion surrounding this topic at my current job.
As an example, consider the following service method:
        public async Task<IEnumerable<User>> GetUsersAsync(
            Guid customerId,
            CancellationToken token = default)
            EnsureArg.IsNotEmpty(customerId, nameof(customerId));

            if (!await CompanyExistsAsync(customerId))
                _logger.LogError(ExceptionMessages.UnknownCustomerException, customerId);

                throw new UnknownCustomerException(ExceptionMessages.UnknownCustomerException, customerId);

            IEnumerable<Data.User> dbUsers = _userRepository.GetUsersForCustomer(customerId);

            var users = _mapper.Map<IEnumerable<User>>(dbUsers);

            return users;
Does AV1200 imply that this is preferred instead of returning result objects with status codes and possibly/optionally an object? E.g. Something like Result<TEntity, TResultCode>.
Dennis Doomen
Oct 17 2018 16:38 UTC
I would throw an exception if the customer ID is invalid
If there are no users, the enumerable is just empty