Я пытаюсь вернуть пустой список
Я новичок в списке, но я пытаюсь вернуть пустой список через метод, чтобы список можно было использовать где-то еще. Но я не знаю, как это сделать.
public List login (String user, String key) < if (success) < System.out.println("Welcome"); return (THIS IS WHERE I WANT TO RETURN AN EMPTY LIST); >System.out.println("Incorrect Information"); return null; > Поделиться Источник 12 марта 2019 в 19:31
3 ответа
Если вы собираетесь использовать его где-то еще, вы можете вернуть любую реализацию интерфейса List . Самый используемый:
new ArrayList<>(); Также есть несколько способов вернуть неизменяемый пустой список (это означает, что вы не можете его изменить):
return Collections.emptyList(); return List.of(); // from java9 Поделиться 12 марта 2019 в 19:41
return new ArrayList<>(); Поделиться 12 марта 2019 в 19:32
java.util.List — это интерфейс, поэтому вы не можете создать его экземпляр.
Вы должны создать один из его классов реализации и вернуть этот объект.
Например, return new ArrayList<>();
Как вернуть пустой список java
Откуда принято в java брать пустые коллексии и мапы?
Вот если в случае ошибки метод возвращает не null а просто пусотй лист, то как лучше сделать?
Объект будет использоваться только для просмотра.
Так?
. List lst = new List; return lst; . Или в джаве есть какие-то константы для пустых коллекций и мап?
Re: Как правильно возвращать пустые List и Map?
| От: | Blazkowicz | |
| Дата: | 30.07.07 20:39 | |
| Оценка: | 4 (4) +2 | |
Здравствуйте, Аноним, Вы писали:
А>Или в джаве есть какие-то константы для пустых коллекций и мап?
Collections.EMPTY_LIST
Collections.EMPTY_MAP
Re[2]: Как правильно возвращать пустые List и Map?
| От: | Andrei N.Sobchuck | www.smalltalk.ru |
| Дата: | 31.07.07 08:26 | |
| Оценка: |
Здравствуйте, Blazkowicz, Вы писали:
А>>Или в джаве есть какие-то константы для пустых коллекций и мап?
B>Collections.EMPTY_LIST
B>Collections.EMPTY_MAP
А если хочется дженериков, то
Collection.emptyList() и т.д.
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
Re[3]: Как правильно возвращать пустые List и Map?
| От: | S_Mall |
| Дата: | 31.07.07 09:54 |
| Оценка: |
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Здравствуйте, Blazkowicz, Вы писали:
Все выше сказанное верно, но если Вы хотите в дальнейшем использовать эти листы, мапы(добавлять элементы, удалять и т.д.), то просто можно не заморачиваясь вернуть new ArrayList(), new HashMap() или любую другую желаемую реализацию List, Map .
В случае же исплользования Collections.emptyList() или emptyMap() при попытке к примеру добавить элемент будет проброшен UnsupportedOperationException
Re[4]: Как правильно возвращать пустые List и Map?
| От: | Blazkowicz |
| Дата: | 31.07.07 09:57 |
| Оценка: |
Здравствуйте, S_Mall, Вы писали:
S_M>Все выше сказанное верно, но если Вы хотите в дальнейшем использовать эти листы, мапы(добавлять элементы, удалять и т.д.), то просто можно не заморачиваясь вернуть new ArrayList(), new HashMap() или любую другую желаемую реализацию List, Map .
S_M>В случае же исплользования Collections.emptyList() или emptyMap() при попытке к примеру добавить элемент будет проброшен UnsupportedOperationException
Это все конечно очень здоровское замечание, только
«Объект будет использоваться только для просмотра.» — исходное условие.
Re[4]: Как правильно возвращать пустые List и Map?
| От: | Аноним |
| Дата: | 31.07.07 14:10 |
| Оценка: |
Здравствуйте, S_Mall, Вы писали:
S_M>Все выше сказанное верно, но если Вы хотите в дальнейшем использовать эти листы, мапы(добавлять элементы, удалять и т.д.), то просто можно не заморачиваясь вернуть new ArrayList(), new HashMap() или любую другую желаемую реализацию List, Map .
И не забыем указывать 0 как initialCapacity для коллекций — зачем пустому ArrayList внутри масив на 10 елементов?
Re[5]: Как правильно возвращать пустые List и Map?
| От: | Blazkowicz |
| Дата: | 01.08.07 07:28 |
| Оценка: |
Здравствуйте, Аноним, Вы писали:
А>И не забыем указывать 0 как initialCapacity для коллекций — зачем пустому ArrayList внутри масив на 10 елементов?
Что возвращать, Empty collection или null?
Собственно сам вопрос, что считается лучшей практикой, вернуть Enumerable.Empty() или null? И указывать возвращаемым типом List или IEnumerable?
Например есть метод возвращающий список адресов, какой вариант будет правильным?
public IEnumerable GetAdresses() < try < return dbContext.Adresses.ToList(); >catch (Exception) < return Enumerable.Empty(); > >public List GetAdresses() < try < return dbContext.Adresses.ToList(); >catch (Exception) < return null;//или что-нибудь вроде new List> >И хотелось бы объяснений.
- Вопрос задан более трёх лет назад
- 1562 просмотра
4 комментария
Оценить 4 комментария
К уже данному ответу стоит также добавить, что делать return из блока catch неправильно. Если коротко — нельзя использовать обработку исключений для неисключительных ситуаций.
Сергей Коновалов @zakar1ya Автор вопроса
Лучше throw ?
Валерий Абакумов @Valeriy1991
Кирилл Таран — согласен полностью. Да, Сергей Коновалов, в блоках catch лучше ставить throw. А еще лучше перед throw ставить логирование. Я бы добавил еще про разницу между
catch(Exception)
catch(Exception ex)
но думаю, Вы это и так знаете.
Сергей Коновалов не заметил вопроса. В данном случае лучше создать переменную до try-catch, и либо наполнять его данными в try, либо возвращать пустой, но в конце. В таком ключе:
public IEnumerable GetAdresses() < var result = Enumerable.Empty() try < result = dbContext.Adresses.ToList(); >catch (Exception ex) < //обработка настоящих ошибок >finally < return result; >>Попробуйте представить, что будет, если произойдёт реальная ошибка и, например, отвалится соединение с базой. Во многих сценариях возвращать какое-то значение уже не понадобится.
Решения вопроса 1
Дмитрий Ковальский @dmitryKovalskiy
программист средней руки
Лучше вернуть пустой список. Бизнес-логика как правило проверяет коллекцию на наличие хоть каких-то элементов(Count/Length>0) или по признаку (Where().Count/Length>0). Возврат NULL предварит эти проверки доп. проверкой на NULL. Лично вы из каких соображений хотите вернуть NULL?
UPD: Есть альтернатива — постоянно ловить NullReferenceException, но с тем же успехом можете использовать оператор goto.
Ответ написан более трёх лет назад
Нравится 3 9 комментариев
Сергей Коновалов @zakar1ya Автор вопроса
Пробую силы в асп, беру из базы список адресов, передаю его в контроллер. Подумал нужно обрабатывать ошибки, если с базой косяк будет и возник вопрос что вернуть в случае провала.
Дмитрий Ковальский @dmitryKovalskiy
Сергей Коновалов: А вот это уже надо было писать в вопросе. На мой взгляд в интерфейс надо бросить некое исключение «DataSourceException». Чтобы пользователю показать что что-то пошло не так, а не «Ничего не найдено».
Совет №1 — передайте в метод хоть какие-то параметры фильтрации. Фильтровать на сервере приложения — плохо. Таскать данные, которые вам не нужны — плохо. Вам точно нужен ВЕСЬ(. ) список адресов? Как правило даже если это так — выводить весь вам не надо, а нужно пагинировать штук по 20.
Сергей Коновалов @zakar1ya Автор вопроса
Адресов всего может быть порядка 20-30, так что показать в данном случае лучше все, но спасибо, учту для других сущностей
Сергей Коновалов @zakar1ya Автор вопроса
Кстати насчет goto? можете показать пример как его тут использовать? и если я не ошибаюсь, его вроде не рекомендуется использовать?
Дмитрий Ковальский @dmitryKovalskiy
Сергей Коновалов: Я к тому что использовать NULL, в паре с ловлей NullReferenceException — чистое применение goto. Код начнет прыгать туда сюда и отладка станет праздником жизни. Лучше отловить конкретные исключения — ошибки чтения данных с выводом конкретной инфы -что-то не так с базой или еще чем-то. NULL для этих целей в принципе можно использовать, но на мой взгляд лучше все-же четко отделять логику работы и возникшие ошибки.Проверка на NULL в данном случае будет проверкой на то что была ошибка и к бизнес-логике никакого отношения не имеет.
Сергей Коновалов: Это был сраказм
Валерий Абакумов @Valeriy1991
Дмитрий Ковальский — не согласен с Вами в том, что всегда лучше возвращать пустой список. Очень часто бизнес-логика бывает такой сложной, что избежать null-объектов почти невозможно. Добавьте сюда еще и ограниченные сроки реализации задач. Разработчику нужно постоянно следить за тем, чтобы не было null-объектов, а по мне — это сущий геморрой. Из личного опыта — гораздо проще обрабатывать null-ситуации (здесь я имею в виду проверку на null, а не обработку NullReferenceException), чем пытаться уйти от null. Все равно никогда от null-ситуаций Вы не уйдете. И проще проверить на null. Тем более, что в C# 6.0 появилась такая замечательная конструкция, как ?.
Дмитрий Ковальский @dmitryKovalskiy
Валерий Абакумов: Спасибо за ваш комментарий, в общем и целом вы правы. Однако есть тонкости. 1) бесспорно null-ситуации возможны. В конце концов поля базы данных допускают Null-значения, и, более того, в C#/.NET есть такая вещь как интерфейс INullable и Nullable-типы, однако это не повод самому себе дополнительно придумывать приключения. 2) и САМОЕ ВАЖНОЕ — автор вопроса подразумевает не возможность вернуть NULL при пустой выдаче, а именно ошибочное поведение. Я убежден что надо строго разделять пустую выдачу и ошибку чтения.Исключительные ситуации в асп, к слову, можно и нужно логировать. Задушенный на раннем этапе Exception с возвратом NULL приведет к тому что в логике контроллеров,страниц мом представлений появится код типа
if(list !=null) else
Валерий Абакумов @Valeriy1991
Дмитрий Ковальский ну да, мой комментарий больше ушел в сторону общего использования null. А что касается данного конкретного вопроса, то я считаю, что в данном методе GetAdresses() при ловле исключения в блоке catch нельзя возвращать ни null, ни Enumerable.Empty. Только throw (вместе с логированием).
Ответы на вопрос 3
Конечно пустую коллекцию.. у тебя даже об этом сигнатура говорит. В случае с Null ты не сможешь передать результат дальше (в функцию принимающую List
Ответ написан более трёх лет назад
Комментировать
Нравится 1 Комментировать
Могу WPF/Silverlight, EF, WCF, T4, ищу работу Мск
Лучше вернуть OperationResult в обоих случаях, например такой:
public class OperationResult < T Result < get; set; >string Message < get; set; >bool IsSuccessful < get; set; >// можно заменить на enum с бОльшим количеством вариантов >Ответ написан более трёх лет назад
Комментировать
Нравится Комментировать
Валерий Абакумов @Valeriy1991
Разработчик .NET C# (ASP.NET MVC) в Alfa-B, Moscow
Правильным будет следующий вариант:
public IEnumerable GetAdresses() < try < return dbContext.Adresses.ToList(); >catch (Exception ex) < // Логируем ошибку - что-то вроде: //_loggerService.Error(ex); throw; >>А снаружи, например, у Вас будет метод, который при ловле исключения будет выдавать что-то осознанное пользователю:
public ActionResult Addresses() < try < var addressList = _dataService.GetAdresses(); return View("_Addresses", addressList); >catch (Exception ex) < TempData["Error"] = "Не удалось загрузить список адресов. Попробуйте позже." return View("_Addresses"); >>Во View я бы тоже советовал всегда делать проверку на null, потому что по независящим от Вас причинам Model спокойно может быть null. И лучше на клиенте такие ситуации обрабатывать, чтобы у Ваших пользователей не было ступора и они не перестали пользоваться Вашим веб-приложением.
@if(Model != null && Model.Any()) < @foreach(var address in Model) > else < @TempData["Error"] >
Пустой список, список из одного элемента, список из массива
Мы уже знакомы с классическим списком ArrayList и неизменяемой обёрткой Collections.unmodifiableList() . Теперь — о некоторых специальных списках.
Список из одного элемента
Если нужен неизменяемый список из одного элемента, используется Collections.singletonList() . Например, так:
class TruePunk < private final ListpreferredMusicGenres = Collections.singletonList("punk"); List getPreferredMusicGenres() < return preferredMusicGenres; >>
Пустой список
Если нужен пустой список, можно использовать Collections.emptyList() . Это неизменяемый список нулевого размера.
class PersonIndifferentToMusic < ListgetPreferredMusicGenres() < return Collections.emptyList(); >>
Список из массива
Мостом между миром массивов и миром списков служит Arrays.asList() . Этот метод создаёт список, который проксирует операции чтения и записи к оригинальному массиву. Его метод add нерабочий (бросает исключение), т. к. размер нижележащего массива неизменен, а методы get(int index) и set(int index, Object value) читают и записывают массив соответственно.
String[] genresArray = < "metal", "metalcore", "symphonic metal", null, null >; System.out.println(Arrays.toString(genresArray)); genresArray[3] = "post-hardcore"; System.out.println(Arrays.toString(genresArray)); List genresList = Arrays.asList(genresArray); genresList.set(4, "progressive metal"); System.out.println(Arrays.toString(genresArray)); System.out.println(genresList);
[metal, metalcore, symphonic metal, null, null] [metal, metalcore, symphonic metal, post-hardcore, null] [metal, metalcore, symphonic metal, post-hardcore, progressive metal] [metal, metalcore, symphonic metal, post-hardcore, progressive metal]