These are chat archives for dennisdoomen/CSharpGuidelines

17th
Oct 2018
Dennis Doomen
@dennisdoomen
Oct 17 2018 12:25
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
@youfoundkris
Oct 17 2018 15:03
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
@dennisdoomen
Oct 17 2018 16:38
I would throw an exception if the customer ID is invalid
If there are no users, the enumerable is just empty