Ошибка возникает здесь
C# | ||
|
Потому что в файле nastroika.txt откуда берутся данные в выше стоящий код пустая строка (или правильно отсутствуют аргументы). При этом выскакивает окошко с исключением System.ArgumentException, которое я и не могу обработать в программе.
Добавлено через 30 минут
Вот информация.
Как обработать возникшее исключение?
Кликните здесь для просмотра всего текста
System.ArgumentException не обработано
HResult=-2147024809
Message=Путь имеет недопустимую форму.
Source=mscorlib
StackTrace:
в System.IO.Path.LegacyNormalizePath(String path, Boolean fullCheck, Int32 maxPathLength, Boolean expandShortPaths)
в System.IO.Path.NormalizePath(String path, Boolean fullCheck, Int32 maxPathLength, Boolean expandShortPaths)
в System.IO.Path.GetFullPathInternal(String path)
в System.IO.DirectoryInfo.Init(String path, Boolean checkHost)
в System.IO.DirectoryInfo..ctor(String path)
в Kofficientu.Form1.button1_Click(Object sender, EventArgs e) в c:Project C#KofficientuKofficientuForm1.cs:строка 127
в System.Windows.Forms.Control.OnClick(EventArgs e)
в System.Windows.Forms.Button.OnClick(EventArgs e)
в System.Windows.Forms.Button.OnMouseUp(MouseEventAr gs mevent)
в System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)
в System.Windows.Forms.Control.WndProc(Message& m)
в System.Windows.Forms.ButtonBase.WndProc(Message& m)
в System.Windows.Forms.Button.WndProc(Message& m)
в System.Windows.Forms.Control.ControlNativeWindow.O nMessage(Message& m)
в System.Windows.Forms.Control.ControlNativeWindow.W ndProc(Message& m)
в System.Windows.Forms.NativeWindow.DebuggableCallba ck(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
в System.Windows.Forms.UnsafeNativeMethods.DispatchM essageW(MSG& msg)
в System.Windows.Forms.Application.ComponentManager. System.Windows.Forms.UnsafeNativeMethods.IMsoCompo nentManager.FPushMessageLoop(IntPtr dwComponentID, Int32 reason, Int32 pvLoopData)
в System.Windows.Forms.Application.ThreadContext.Run MessageLoopInner(Int32 reason, ApplicationContext context)
в System.Windows.Forms.Application.ThreadContext.Run MessageLoop(Int32 reason, ApplicationContext context)
в System.Windows.Forms.Application.Run(Form mainForm)
в Kofficientu.Program.Main() в c:Project C#KofficientuKofficientuProgram.cs:строка 19
в System.AppDomain._nExecuteAssembly(RuntimeAssembly assembly, String[] args)
в System.AppDomain.ExecuteAssembly(String assemblyFile, Evidence assemblySecurity, String[] args)
в Microsoft.VisualStudio.HostingProcess.HostProc.Run UsersAssembly()
в System.Threading.ThreadHelper.ThreadStart_Context( Object state)
в System.Threading.ExecutionContext.RunInternal(Exec utionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
в System.Threading.ExecutionContext.Run(ExecutionCon text executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
в System.Threading.ExecutionContext.Run(ExecutionCon text executionContext, ContextCallback callback, Object state)
в System.Threading.ThreadHelper.ThreadStart()
InnerException:
0
Содержание
- Исключения (Exceptions) и инструкция try
- Оговорка catch
- Блок finally
- Инструкция using
- Выбрасывание исключений
- Основные свойства System.Exception
- Основные типы исключений
- Директивы препроцессора
- Pragma Warning
- Атрибут Conditional
- Классы Debug и Trace
- TraceListener
- Fail и Assert
Исключения, их обработка, и некоторые другие моменты, связанные с ошибками в приложении на C#.
Исключения (Exceptions) и инструкция try
Инструкция try
отмечает блок кода как объект для обработки ошибок или очистки. После блока try
обязательно должен идти либо блок catch
, либо блок finally
, либо они оба. Блок catch
выполняется, когда внутри блока try возникает ошибка. Блок finally
выполняется после того, как прекращает выполнять блок try
(или, если присутствует, блок catch
), независимо от того, выполнился ли он до конца или был прерван ошибкой, что позволяет выполнить так называемый код очистки.
Блок catch
имеет доступ к объекту исключения (Exception
), который содержит информацию об ошибке. Блок catch
позволяет обработать исключительную ситуацию и как-либо скорректировать ошибку или выбросить новое исключение. Повторное выбрасывание исключения в блоке catch
обычно применяется с целью логирования ошибок или чтобы выбросить новое, более специфическое исключение.
Блок finally
добавляет в программу прогнозируемость, позволяя выполнить определенный код при любых обстоятельствах. Это может быть полезно для выполнения операций очистки, например, закрытия сетевого подключения и т.д.
В целом конструкция try выглядит следующим образом:
try { ... // в пределах этого блока может быть выброшено исключение } catch (ExceptionA ex) { ... // обработчик исключений типа ExceptionA } catch (ExceptionB ex) { ... // обработчик исключений типа ExceptionB } finally { ... // код очистки } |
Например, следующий код выбросит ошибку DivideByZeroException
(поскольку делить на ноль нельзя) и наша программа завершить досрочно:
int x = 3, y = 0; Console.WriteLine (x / y); |
Чтобы этого избежать можно использовать конструкцию try
:
try { int x = 3, y = 0; Console.WriteLine (x / y); } catch (DivideByZeroException ex) { Console.Write («y cannot be zero. «); } // выполнение программы продолжится отсюда |
Обработка исключений довольно ресурсоёмкая операция, поэтому на практике для таких случаев как в примере ее лучше не использовать (лучше непосредственно перед делением проверить делить на равенство нулю).
Когда выбрасывается исключение, CLR проверяет выброшено ли оно непосредственно внутри блока try
, который может обработать данное исключение. Если да, выполнение переходит в соответствующий блок catch
. Если блок catch
успешно завершается, выполнение переходит к следующей после блока try
инструкции (если имеется блок finally
, то сначала выполняется он). Если же исключение выброшено не внутри блока try
или конструкция try
не содержит соответствующего блока catch
, выполнение переходит в точку вызова метода (при этом сначала выполняется блок finally
), и проверка повторяется снова.
Если не одна функция в стэке вызовов не способна обработать исключение, ошибка выводиться пользователю и программа завершается досрочно.
Оговорка catch
В оговорке catch указывается какой тип исключения она должна перехватывать. Это может быть либо System.Exception
, либо его производный класс. Перехватывая непосредственно System.Exception
, мы перехватим все возможные ошибки. Это может быть полезно в нескольких случаях:
- программа потенциально должна и может продолжить работать несмотря на ошибки любых типов
- исключение будет выброшено повторно в блоке
catch
, например, после логирования ошибок - блок
catch
является последним в очереди, способным предотвратить аварийное завершение программы
Однако обычно перехватываются исключения более специфического типа, чтобы избежать ситуации, когда обработчику ошибки придется иметь дело с исключением, для которого он не предназначен (например, OutOfMemoryException
).
Можно обработать несколько типов исключений с помощью нескольких оговорок catch:
try { DoSomething(); } catch (IndexOutOfRangeException ex) { ... } catch (FormatException ex) { ... } catch (OverflowException ex) { ... } |
Каждая оговорка способна обработать только то исключение, которое точно совпадает с ее типом. Для одного выброшенного исключения может быть выполнена только одна оговорка catch. Обрабатываются блоки catch в том порядке, в котором они идут в коде. В этой связи более специфические исключения должны перехватываться раньше чем более общие.
Исключение может быть перехвачено и без указания переменной, если не нужен доступ к ее членам:
catch (StackOverflowException) // без переменной { ... } |
Более того, в оговорке catch можно опустить и переменную и тип исключения — такая оговрка будет перехватывать все исключения:
Блок finally
Блок finally
выполняется всегда, независимо от того выброшено исключение или нет. Блок finally
обычно содержит код очистки.
Блок finally
выполняется в следующих случаях:
- после завершения блока
catch
- если выполнение блока
try
прервано jump-инструкциями:return
,goto
и т.д. - после выполнения блока
try
полностью, если исключений так и не было выброшено
Блок finally
делает программу более прогнозируемой. Например, в следующем примере открываемый файл в итоге всегда будет закрыт, независимо от того, завершиться ли блок try
без ошибок, или будет прерван выброшенным исключением, или сработает инструкция return
если файл окажется пустым:
static void ReadFile() { StreamReader reader = null; try { reader = File.OpenText («file.txt»); if (reader.EndOfStream) return; Console.WriteLine (reader.ReadToEnd()); } finally { if (reader != null) reader.Dispose(); } } |
В пример для закрытия файла вызывается метод Dispose
. Использование этого метода внутри блока finally
является стандартной практикой. C# даже позволяет заменить всю конструкцию инструкцией using
.
Инструкция using
Многие классы инкапсулируют неуправляемые ресурсы, такие как дескриптор файла, соединение с базой данных и т.д. Эти классы реализуют интерфейс System.IDisposable
, который содержит единственный метод без параметров Dispose
, освобождающий соответствующие машинные ресурсы. Инструкция using
предусматривает удобный синтаксис вызова метода Dispose
для объектов реализующих IDisposable
внутри блока finally
:
using (StreamReader reader = File.OpenText («file.txt»)) { ... } |
Что эквивалентно следующей конструкции:
StreamReader reader = File.OpenText («file.txt»); try { ... } finally { if (reader != null) ((IDisposable)reader).Dispose(); } |
Выбрасывание исключений
Исключение может быть выброшено автоматически во время выполнения программы либо явно в коде программы с помощью ключевого слова throw
:
static void Display (string name) { if (name == null) throw new ArgumentNullException («name»); Console.WriteLine (name); } |
Также исключение может быть выброшено повторно внутри блока catch
:
try { ... } catch (Exception ex) { // логирование ошибки ... throw; // повторное выбрасывание того же самого исключения } |
Такой подход позволяет заносить ошибки в лог без их дальнейшего поглощения. Также это позволяет уклониться от обработки неожиданных исключений.
Если throw
заменить на throw ex
, то пример по прежнему будет работать, но свойство исключения StackTrace
не будет отражать исходную ошибку.
Другой распространенный сценарий использования повторного выбрасывания исключения — повторное выбрасывание более специфического и конкретного типа исключения, чем было перехвачено ранее:
try { ... // парсинг даты рождения из xml-данных } catch (FormatException ex) { throw new XmlException («Неправильная дата рождения», ex); } |
В таких случаях необходимо передать исходное исключение в качестве первого параметра конструктора нового исключения, ссылка на объект исходного исключения позже будет доступна через свойство InnerException
внутреннего исключения.
Основные свойства System.Exception
К наиболее важным свойствам класса System.Exception
можно отнести:
StackTrace
— строка, представляющая все методы, которые были вызваны, начиная с того, в котором было выброшено исключение, и заканчивая тем, в котором содержится блокcatch
, перехвативший исключение;Message
— строка с описанием ошибки;InnerException
— содержит ссылку на объектExeption
, который вызвал текущее исключение (например, при повторном выбрасывании исключения).
Основные типы исключений
Следующие типы исключений являются наиболее распространенными в среде CLR и .NET Framework. Их можно выбрасывать непосредственно или использовать как базовые классы для пользовательских типов исключений.
System.ArgumentException
— выбрасывается при вызове функции с неправильным аргументом.System.ArgumentNullException
— производный отArgumentException
класс, выбрасывается если один из аргументов функции неожиданно равенnull
.System.ArgumentOutOfRangeException
— производный отArgumentException
класс, выбрасывается когда аргумент функции имеет слишком большое или слишком маленькое значение для данного типа (обычно касается числовых типов). Например, такое исключение будет выброшено если попытаться передать отрицательное число в функцию, которая ожидает только положительные числа.System.InvalidOperationException
— выбрасывается когда состояние объекта является неподходящим для нормального выполнения метода, например, при попытке прочесть не открытый файл.System.NotSupportedException
— выбрасывается, когда запрошенный функционал не поддерживается, например, если попытаться вызвать методAdd
для коллекции доступной только для чтения (свойство коллекцииIsReadOnly
возвращаетtrue
).System.NotImplementedException
— выбрасывается, когда запрошенный функционал еще не реализован.System.ObjectDisposedException
— выбрасывается при попытке вызвать метод объекта, который уже был уничтожен (disposed).
Директивы препроцессора
Директивы препроцессора снабжают компилятор дополнительной информацией об областях кода. Самые распространенные директивы препроцессора — условные директивы, позволяющие включить или исключить области кода из компиляции.
#define DEBUG class MyClass { int x; void Foo() { # if DEBUG Console.WriteLine («Testing: x = {0}», x); # endif } } |
В этом классе инструкции в методе Foo
скомпилируются если определен символ DEBUG
, а если его удалить — инструкции не скомпилируются. Символы препроцессора могут быть определены в исходном коде (как в примере), а могут быть переданы компилятору в командной строке с помощью параметра /define:symbol
.
С директивами #if
и #elif
можно использовать операторы ||
, &&
и !
с несколькими символами:
Директивы #error
и #warning
предотвращают некорректное использование условных директив, заставляя компилятор генерировать предупреждение или ошибку при передаче неверного набора символов.
Директивы препроцессора схожи с условными конструкциями и статическими переменными, однако дают возможности, недоступные для последних:
- условное включение атрибута
- изменение типа, объявляемого для переменной
- переключение между разными пространствами имен или псевдонимами типа в директиве using:
using TestType =
#if V2
MyCompany.Widgets.GadgetV2;
#else
MyCompany.Widgets.Gadget;
#endif
- создавать новые версии кода и быстро переключаться между ними при компиляции
- создавать библиотеки, компилируемые для разных версий .NET Framework
Полный список директив препроцессора:
#define symbol
— определяет символ#undef symbol
— удаляет символ#if symbol [оператор symbol2]...
— условная компиляция; допустимые операторы==
,!=
,&&
и||
#else
— выполняет код после#endif
#elif symbol [оператор symbol2]
— объединяет#else
и#if
#endif
— конец условных директив#warning text
— текст предупреждения, которое появится в выдаче компилятора#error text
— текст ошибки, которая появится в выдаче компилятора#line [число["файл"] | hidden]
— число указывает номер строки в исходном коде; файл — имя файла, которое появится в выдаче компилятора; hidden — дает указание дебагеру пропустить код от этой точки до следующей директивы#line
#region name
— отмечает начало области#endregion
— отмечает конец области#pragma warning
Pragma Warning
Компилятор генерирует предупреждения, когда что-то в коде ему кажется неуместным (но корректным). В отличии от ошибок предупреждения не препятствуют компиляции программы. Предупреждения компилятора могут быть очень полезны при поиске багов в программе. Однако часто предупреждения оказываются ложными, поэтому целесообразно иметь возможность получать предупреждения только о действительных багах. С этой целью компилятор дает возможность выборочно подавить предупреждения с помощью директивы #pragma warning
.
public class Foo { static void Main() { } #pragma warning disable 414 static string Message = «Hello»; #pragma warning restore 414 } |
В примере мы указываем компилятору не выдавать предупреждения о том, что поле Message
не используется.
Если не указывать номер директива #pragma warning
отменит или восстановит вывод всех предупреждений.
Если скомпилировать программу с параметром /warnaserror
, то все не отмененные директивой #pragma warning
предупреждения будут расцениваться компилятором как ошибки.
Атрибут Conditional
Атрибут Conditional
указывает компилятору на необходимость игнорировать все обращения к определенному классу или методу, если заданный символ не был определен:
[Conditional («LOGGINGMODE»)] static void LogStatus (string msg) { ... } |
Это равносильно тому, что каждый вызов метода будет окружен условными директивами:
#if LOGGINGMODE LogStatus («Message Headers: « + GetMsgHeaders()); #endif |
Классы Debug и Trace
Статические классы Debug
и Trace
предлагают базовые возможности логирования. Оба класса схожи, отличие заключается в их назанчении. Класс Debug
предназначен для отладочных сборок, класс Trace
— для отладочных и финальных. В связи с этим все методы класса Debug
определены с атрибутом [Conditional("DEBUG")]
, а методы класса Trace
— с атрибутом [Conditional("TRACE")]
. Это значит, что все обращения к Debug
и Trace
будут подавляться компилятором, пока не определен символ DEBUG
или TRACE
.
Класс Debug
и Trace
определяют методы Write
, WriteLine
и WriteIf
. По умолчанию они отправляют сообщения в окно вывода отладчика:
Debug.Write («Data»); Debug.WriteLine (23 * 34); int x = 5, y = 3; Debug.WriteIf (x > y, «x is greater than y»); |
Класс Trace
также содержит методы TraceInformation
, TraceWarning
и TraceError
. Их действия зависят от зарегистрированных прослушивателей.
TraceListener
Классы Debug
и Trace
имеют свойство Listeners
, которое представляет собой статическую коллекцию экземпляров TraceListener
. Они отвечают за обработку данных, возвращаемых методами Write
, Fail
и Trace
.
По умолчанию коллекция Listeners
обоих классов включает единственный прослушиватель — DefaultTraceListener
— стандартный прослушиватель, имеющий две ключевые возможности:
- при подключении к отладчику (например, Visual Studio) сообщения записываются в окно вывода отладчика, во всех остальных случаях сообщения игнорируются
- при вызове метода
Fail
отображается диалоговое окно, запрашивающее у пользователя дальнейшие действия: продолжить, прервать или повторить отладку (независимо от того, подключен ли отладчик)
Это поведение можно изменить или дополнить, удалив (на обязательно) стандартный прослушиватель и/или добавив один или более собственных прослушивателей.
Прослушиваетли трассировки можно написать с нуля (создав производный класс от TraceListener
) или воспользоваться готовыми классами:
TextWriterTraceListener
записывает вStream
илиTextWriter
или добавляет в файл; имеет четыре подкласса:ConsoleTraceListener
,DelimitedListTraceListener
,XmlWriterTraceListener
иEventSchemaTraceListener
EventLogTraceListener
записывает в журнал событий WindowsEventProviderTraceListener
записывает в систему трассировки событий Windows (Event Tracing for Windows — ETW)WebPageTraceListener
выводит на веб-страницу ASP.NET
Ни один из этих прослушивателе не отображает диалоговое окно при вызове Fail
, это делает только DefaultTraceListener
.
// Удалить стандартный прослушиватель, очистив коллекцию прослушивателей: Trace.Listeners.Clear(); // Добавить средство записи в файл trace.txt: Trace.Listeners.Add (new TextWriterTraceListener («trace.txt»)); // Добавит средство записи в консоль: System.IO.TextWriter tw = Console.Out; Trace.Listeners.Add (new TextWriterTraceListener (tw)); // Добавить средство записи в журнал событий Windows: if (!EventLog.SourceExists («DemoApp»)) EventLog.CreateEventSource («DemoApp», «Application»); Trace.Listeners.Add (new EventLogTraceListener («DemoApp»)); |
В случае журнала событий Windows сообщения, отправляемые с помощью Write
, Fail
или Assert
, записываются как сведения, а сообщения методов TraceWarning
и TraceError
записываются как предупреждения или ошибки.
Каждый экземпляр TraceListener
имеет свойство Filter
и TraceFilter
, с помощью которых можно управлять, будет ли сообщение записано в этот прослушиватель. Для этого необходимо создать экземпляр классов EventTypeFilter
или SourceFilter
(производных от TraceFilter
) или создать свой класс, наследующий от TraceFilter
и переопределить в нем метод ShouldTrace
.
В TraceListener
также определены свойства IndentLevel
и IndentSize
для управления отступами и свойство TraceOutputOptions
для записи дополнительных данных:
TextWriterTraceListener tl = new TextWriterTraceListener (Console.Out); tl.TraceOutputOptions = TraceOptions.DateTime | TraceOptions.Callstack; // Это применяется при использовании метода Trace: Trace.TraceWarning («Orange alert»); DiagTest.vshost.exe Warning: 0 : Orange alert DateTime=2007—03—08T05:57:13.6250000Z Callstack= at System.Environment.GetStackTrace(Exception e, Boolean needFileInfo) at System.Environment.get_StackTrace() at ... |
Прослушиватели, которые записывают данные в поток, кэшируются. По этой причине данные не появляются в потоке немедленно, а также поток перед завершением приложения должен быть закрыт, или хотя бы сброшен, чтоб не потерять данные в кэше. Для этой цели классы Trace
и Debug
содержат статические методы Close
и Flush
, которые вызывают Close
и Flush
во всех прослушивателях (а они в свою очередь закрывают или сбрасывают все потоки). Метод Close
вызывает метод Flush
, закрывает файловые дескрипторы и предотвращает дальнейшую запись.
Классы Trace
и Debug
также определяют свойство AutoFlush
, которое если равно true
вызывает Flush
после каждого сообщения.
Fail и Assert
Классы Debug
и Trace
содержат методы Fail
и Assert
.
Метод Fail
отправляет сообщения каждому TraceListener
:
Debug.Fail («File data.txt does not exist!»); |
Метод Assert
вызывает Fail
если аргумент типа bool
равен false
. Это называется созданием утверждения и указывает на ошибку, если оно нарушено. Можно также создать необязательное сообщение об ошибке:
Debug.Assert (File.Exists («data.txt»), «File data.txt does not exist!»); var result = ... Debug.Assert (result != null); |
Методы Write
, Fail
и Assert
также могут принимать категорию в виде строки ,которая может быть использована при обработке вывода.
Содержание
- Элемент с тем же ключом уже добавлен
- ViewPage
- ОТВЕТЫ
- Ответ 1
- Ответ 2
- Ответ 3
- Ответ 4
- Ответ 5
- Ответ 6
- Ответ 7
- Ответ 8
- Ответ 9
- Ответ 10
- Ответ 11
- Ответ 12
- Ответ 13
- Ответ 14
- Ответ 15
- Ответ 16
- Ответ 17
- Ответ 18
- ArgumentException: элемент с тем же ключом уже был добавлен ошибка
- 2 ответа
- Элемент с тем же ключом уже добавлен
- ViewPage
Элемент с тем же ключом уже добавлен
Я получаю эту ошибку всякий раз, когда я отправляю форму, также метод действия не вызывается из-за этого:
Элемент с тем же ключом уже добавлен.
И сведения об исключении:
[ArgumentException: элемент с тот же ключ уже добавлен.]
System.ThrowHelper.ThrowArgumentException(ExceptionResource ресурс) +52
System.Collections.Generic.Dictionary`2.Insert(TKey ключ, значение TValue, Boolean add) +9382923 System.Linq.Enumerable.ToDictionary(IEnumerable`1 source, Func`2 keySelector, Func`2 elementSelector, IEqualityComparer`1 сравнительный) +252
System.Linq.Enumerable.ToDictionary(IEnumerable`1 source, Func`2 keySelector, Сравнение IEqualityComparer`1) +91
System.Web.Mvc.ModelBindingContext.get_PropertyMetadata() +228 System.Web.Mvc.DefaultModelBinder.BindProperty(ControllerContext controllerContext, ModelBindingContext bindingContext, PropertyDescriptor свойствоDescriptor) +392
System.Web.Mvc.DefaultModelBinder.BindProperties(ControllerContext controllerContext, ModelBindingContext bindingContext) +147
System.Web.Mvc.DefaultModelBinder.BindComplexElementalModel(ControllerContext controllerContext, ModelBindingContext bindingContext, Object model) +98
System.Web.Mvc.DefaultModelBinder.BindComplexModel(ControllerContext controllerContext, ModelBindingContext bindingContext) +2504
System.Web.Mvc.DefaultModelBinder.BindModel(ControllerContext controllerContext, ModelBindingContext bindingContext) +548
System.Web.Mvc.ControllerActionInvoker.GetParameterValue(ControllerContext controllerContext, ParameterDescriptor parameterDescriptor) +473
System.Web.Mvc.ControllerActionInvoker.GetParameterValues (ControllerContext controllerContext, ActionDescriptor actionDescriptor) +181
System.Web.Mvc.ControllerActionInvoker.InvokeAction(ControllerContext controllerContext, String actionName) +830 System.Web.Mvc.Controller.ExecuteCore() +136 System.Web.Mvc.ControllerBase.Execute(RequestContext requestContext) +111
System.Web.Mvc.ControllerBase.System.Web.Mvc.IController.Execute(RequestContext requestContext) +39
System.Web.Mvc C__DisplayClass8.b__4() +65 System.Web.Mvc.Async. c__DisplayClass1.b__0() +44 System.Web.Mvc.Async. c__DisplayClass8`1.b__7 (IAsyncResult _) +42 System.Web.Mvc.Async.WrappedAsyncResult`1.End() +141 System.Web.Mvc.Async.AsyncResultWrapper.End(IAsyncResult asyncResult, тег объекта) +54
System.Web.Mvc.Async.AsyncResultWrapper.End(IAsyncResult asyncResult, Object tag) +40
System.Web.Mvc.MvcHandler.EndProcessRequest(IAsyncResult asyncResult) +52
System.Web.Mvc.MvcHandler.System.Web.IHttpAsyncHandler.EndProcessRequest(IAsyncResult результат) +38
System.Web.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() +8836913 System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean & completedSynchronously) +184
ViewPage
ОТВЕТЫ
Ответ 1
Скорее всего, у вас есть модель, которая содержит одно и то же свойство дважды. Возможно, вы используете new , чтобы скрыть базовое свойство.
Решение — переопределить свойство или использовать другое имя.
Если вы поделитесь своей моделью, мы сможем подробнее разобраться.
Ответ 2
У меня была такая же проблема, и я решил это. У меня было двойное свойство с тем же именем в моей модели ViewModel. Одно свойство было в BaseViewModel, а другое — в производной модели.
Я изменил это на
Теперь он работает нормально.
Ответ 3
У меня была аналогичная проблема, и я обнаружил, что это связано с тем, что у меня было аналогичное публичное свойство (которое должно было быть частным), которое только отличалось в случае.
Ответ 4
У меня было 2 свойства модели, подобные этому
Странно, что он выбросил эту ошибку для этих двух ха-ха..
Ответ 5
У меня была проблема не в моей модели С#, а в объекте javascript, который я отправлял с помощью AJAX. Я использую Angular для привязки и имел заглавное поле Notes на странице, а мой объект С# ожидал нижний регистр Notes . Более описательная ошибка будет приятной.
Ответ 6
Я нашел ответ. Это было из-за переменных. Как int a и string a. были две переменные с тем же именем.
Ответ 7
У меня была одна и та же проблема: я был foreach , зацикливая на моем объекте и добавляя результат в Dictionary , и у меня был `Duplicate в ключе из базы данных
item.x имеет двойное значение
Ответ 8
Моя проблема заключалась в том, что у меня был @Url.Action, и я дважды отправил значение для того же свойства
Ответ 9
Вот что я сделал, чтобы узнать ключ, который добавляется дважды. Я загрузил исходный код из http://referencesource.microsoft.com/DotNetReferenceSource.zip и настроил VS для отладки исходного кода. Открытый Dictionary.cs в VS запускал проект, после загрузки страницы добавлял отладку в строке ThrowHelper.ThrowArgumentException(ExceptionResource.Argument_AddingDuplicate); и мог видеть значение «ключ». Я понял, что в JSON одна буква переменной была в верхнем регистре, но в моей модели она была строчной. Я исправил модель и теперь работает тот же код.
Ответ 10
Я попал в это в MVC 5 и Visual Studio Express 2013. У меня было два свойства с IndexAttribute , как показано ниже. Комментируя один из них и перекомпилировав, выстроили в лесу контроллер MVC 5 с представлениями, используя Entity Framework. Загадочно, когда я раскоментировал атрибут, перекомпилировал и снова попытался, scaffolder работал нормально.
Возможно, базовая модель данных сущностей или «что-то» была кэширована/повреждена, а удаление и повторное добавление IndexAttribute просто вызвало перестроение этого «чего-то».
Ответ 11
В MVC 5 я обнаружил, что временно комментирует ссылки на модель Entity Framework и перекомпилирует сторону проекта, выполнив эту ошибку при создании лесов. Как только я закончу строительные леса, я раскомментирую код.
Ответ 12
Я хотел бы добавить ответ, который я не вижу здесь. Это очень связано с принятым ответом, однако у меня не было дублированных свойств на моей модели, это была проблема с моим Javascript.
Я делал некоторое спасение Ajax, где я перестраивал модель для отправки обратно на сервер. Когда я сначала инициализировал страницу, я установил свою исходную модель в переменную:
My result.Data имеет свойство: result.Data.Items
Итак, через некоторое время я кое-что делаю и хочу сэкономить через Ajax. Часть процесса состоит в том, чтобы захватить массив из некоторого побочного процесса и установить его в мое свойство currentModel.Items и отправить currentModel на сервер.
В моем Javascript, однако, я сделал это, вместо этого:
Я не поймал его, но в Visual Studio он автоматически запустит первую букву для свойств Javascript (это тоже может быть ReSharper). Затем я получил точную ошибку, отправленную OP при попытке сохранить, поскольку currentModel теперь имеет currentModel.Items И currentModel.Items
Простая замена «пунктов» на «Элементы» устраняет проблему.
Ответ 13
У меня была такая же проблема. Он появился для меня после перехода на MVC 5 из MVC 3.
У меня был пользовательский шаблон редактора и ему пришлось использовать его так:
Чтобы решить проблему, мне пришлось удалить проходящий объект ViewData . Поэтому в конце я имел:
Надеюсь, что это поможет.
Ответ 14
У меня была такая же ошибка. И после того, как я уже думал, что мой ум сломан, потому что я переименовал почти все свойства моих моделей, решение было удалить одну ссылку на All Syncfusion Controls и добавить ссылки на отдельные элементы управления этого элемента управления. (От Nuget)
Ответ 15
В моем случае корень проблемы был двойным именем свойства в клиенте json, который отличался только чувствительностью к регистру.
Ответ 16
Другой способ встретить эту ошибку — из набора данных с неназванными столбцами. Ошибка генерируется, когда набор данных сериализуется в JSON.
Это утверждение приведет к ошибке:
Добавление имен столбцов предотвратит ошибку:
Ответ 17
У меня была такая же ошибка, но б/с по разным причинам. Использование Entity Framework. Еще одна вещь, которую я должен добавить здесь, прежде чем я поделюсь своим кодом и решением, у меня была точка останова на методе контроллера, но он не ломался там, просто выдает исключение 500 внутренняя ошибка сервера.
Я отправлял данные из представления в контроллер через ajax (http post). Модель, которую я ожидал в качестве параметра, была классом. Это было унаследовано с другим классом.
Просто удалили дублированные поля из класса PurchaseOrder, и это сработало как прелесть.
Ответ 18
В моем случае, просто когда вы компилируете код, он работает просто отлично. Но вызов одного из статического поля статического класса, имеющего словарь, как в примере кода, вызывает исключение.
Образец кода
Пояснение ADict имеет дважды добавленный ключ «test». Итак, когда вы вызываете статический класс, он выдает исключение.
Источник
ArgumentException: элемент с тем же ключом уже был добавлен ошибка
Это странно, я переместил некоторый код, который был первоначально проверен в некотором автономном программном обеспечении, в основное программное обеспечение.
Ошибка при отладке:
Когда я проверяю, из какой строки исходит ошибка, она говорит, что находится в строке вызова: Invoke(new MethodInvoker(() =>
Кажется, что при отладке больше код не идет дальше этой части:
Я включил ниже используемые методы:
Я никогда не писал вышеупомянутый код, он был недавно изменен, который работал в автономном приложении, но не после того, как я переместил точный код с помощью копирования / вставки, из чтения об ошибке, которую я думаю делать со словарем, это будет правильно? я не совсем уверен в проблеме, есть ли что-то выделяющееся в коде, который я мог пропустить? любая помощь будет оценена.
2 ответа
Сообщение об исключении говорит нам, что мы пытаемся добавить ключ в словарь, который уже содержит этот ключ, что недопустимо. Единственный код, которым вы поделились, который делает это:
Чтобы избежать проблемы, мы просто сначала проверяем, существует ли ключ. Если это так, у нас есть решение сделать:
- Оставьте существующее значение
- Назначьте новое значение
Чтобы оставить существующие значения, мы можем просто игнорировать ключи, которые уже существуют:
Чтобы назначить новое значение, нам не нужно проверять, существует ли ключ, мы просто добавляем его другим способом:
Похоже, что ваша проблема здесь.
Не зная базовой структуры данных, я бы предположил, что каждая строка содержит данные для разных объектов одного типа. При этом будет работать нормально, если у вас будет только одна строка, но как только вы попытаетесь перейти на следующую строку, вы получите эту ошибку. По сути, я предполагаю, что ваши данные выглядят так, как показано ниже.
Если это так, то вы на самом деле имеете дело с List > , и вы получите значение для John просто отлично, но с ошибкой Jane произойдет ошибка, потому что вы пытаетесь добавить <> в тот же словарь, в котором находится John . Я близок к вашей ситуации? Если это так, вы можете исправить это, используя следующее.
Это, конечно, прервет ваш вызов этому методу. Если вы знаете, что это всегда первый (или, по крайней мере, знаете, что он всегда находится в определенной позиции), вы можете использовать следующее.
Источник
Элемент с тем же ключом уже добавлен
Я получаю эту ошибку всякий раз, когда я отправляю форму, также метод действия не вызывается из-за этого:
Элемент с тем же ключом уже добавлен.
И сведения об исключении:
[ArgumentException: элемент с тот же ключ уже добавлен.]
System.ThrowHelper.ThrowArgumentException(ExceptionResource ресурс) +52
System.Collections.Generic.Dictionary`2.Insert(TKey ключ, значение TValue, Boolean add) +9382923 System.Linq.Enumerable.ToDictionary(IEnumerable`1 source, Func`2 keySelector, Func`2 elementSelector, IEqualityComparer`1 сравнительный) +252
System.Linq.Enumerable.ToDictionary(IEnumerable`1 source, Func`2 keySelector, Сравнение IEqualityComparer`1) +91
System.Web.Mvc.ModelBindingContext.get_PropertyMetadata() +228 System.Web.Mvc.DefaultModelBinder.BindProperty(ControllerContext controllerContext, ModelBindingContext bindingContext, PropertyDescriptor свойствоDescriptor) +392
System.Web.Mvc.DefaultModelBinder.BindProperties(ControllerContext controllerContext, ModelBindingContext bindingContext) +147
System.Web.Mvc.DefaultModelBinder.BindComplexElementalModel(ControllerContext controllerContext, ModelBindingContext bindingContext, Object model) +98
System.Web.Mvc.DefaultModelBinder.BindComplexModel(ControllerContext controllerContext, ModelBindingContext bindingContext) +2504
System.Web.Mvc.DefaultModelBinder.BindModel(ControllerContext controllerContext, ModelBindingContext bindingContext) +548
System.Web.Mvc.ControllerActionInvoker.GetParameterValue(ControllerContext controllerContext, ParameterDescriptor parameterDescriptor) +473
System.Web.Mvc.ControllerActionInvoker.GetParameterValues (ControllerContext controllerContext, ActionDescriptor actionDescriptor) +181
System.Web.Mvc.ControllerActionInvoker.InvokeAction(ControllerContext controllerContext, String actionName) +830 System.Web.Mvc.Controller.ExecuteCore() +136 System.Web.Mvc.ControllerBase.Execute(RequestContext requestContext) +111
System.Web.Mvc.ControllerBase.System.Web.Mvc.IController.Execute(RequestContext requestContext) +39
System.Web.Mvc C__DisplayClass8.b__4() +65 System.Web.Mvc.Async. c__DisplayClass1.b__0() +44 System.Web.Mvc.Async. c__DisplayClass8`1.b__7 (IAsyncResult _) +42 System.Web.Mvc.Async.WrappedAsyncResult`1.End() +141 System.Web.Mvc.Async.AsyncResultWrapper.End(IAsyncResult asyncResult, тег объекта) +54
System.Web.Mvc.Async.AsyncResultWrapper.End(IAsyncResult asyncResult, Object tag) +40
System.Web.Mvc.MvcHandler.EndProcessRequest(IAsyncResult asyncResult) +52
System.Web.Mvc.MvcHandler.System.Web.IHttpAsyncHandler.EndProcessRequest(IAsyncResult результат) +38
System.Web.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() +8836913 System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean & completedSynchronously) +184
ViewPage
Скорее всего, у вас есть модель, которая содержит одно и то же свойство дважды. Возможно, вы используете new , чтобы скрыть базовое свойство.
Решение – переопределить свойство или использовать другое имя.
Если вы поделитесь своей моделью, мы сможем подробнее разобраться.
У меня была такая же проблема, и я решил это. У меня было двойное свойство с тем же именем в моей модели ViewModel. Одно свойство было в BaseViewModel, а другое – в производной модели.
Я изменил это на
Теперь он работает нормально.
У меня была аналогичная проблема, и я обнаружил, что это связано с тем, что у меня было аналогичное публичное свойство (которое должно было быть частным), которое только отличалось в случае.
У меня было 2 свойства модели, подобные этому
Странно, что он выбросил эту ошибку для этих двух ха-ха..
У меня была проблема не в моей модели С#, а в объекте javascript, который я отправлял с помощью AJAX. Я использую Angular для привязки и имел заглавное поле Notes на странице, а мой объект С# ожидал нижний регистр Notes . Более описательная ошибка будет приятной.
Я нашел ответ. Это было из-за переменных. Как int a и string a. были две переменные с тем же именем.
У меня была одна и та же проблема: я был foreach , зацикливая на моем объекте и добавляя результат в Dictionary , и у меня был `Duplicate в ключе из базы данных
item.x имеет двойное значение
Моя проблема заключалась в том, что у меня был @Url.Action, и я дважды отправил значение для того же свойства
Вот что я сделал, чтобы узнать ключ, который добавляется дважды. Я загрузил исходный код из http://referencesource.microsoft.com/DotNetReferenceSource.zip и настроил VS для отладки исходного кода. Открытый Dictionary.cs в VS запускал проект, после загрузки страницы добавлял отладку в строке ThrowHelper.ThrowArgumentException(ExceptionResource.Argument_AddingDuplicate); и мог видеть значение “ключ”. Я понял, что в JSON одна буква переменной была в верхнем регистре, но в моей модели она была строчной. Я исправил модель и теперь работает тот же код.
Я попал в это в MVC 5 и Visual Studio Express 2013. У меня было два свойства с IndexAttribute , как показано ниже. Комментируя один из них и перекомпилировав, выстроили в лесу контроллер MVC 5 с представлениями, используя Entity Framework. Загадочно, когда я раскоментировал атрибут, перекомпилировал и снова попытался, scaffolder работал нормально.
Возможно, базовая модель данных сущностей или “что-то” была кэширована/повреждена, а удаление и повторное добавление IndexAttribute просто вызвало перестроение этого “чего-то”.
В MVC 5 я обнаружил, что временно комментирует ссылки на модель Entity Framework и перекомпилирует сторону проекта, выполнив эту ошибку при создании лесов. Как только я закончу строительные леса, я раскомментирую код.
Я хотел бы добавить ответ, который я не вижу здесь. Это очень связано с принятым ответом, однако у меня не было дублированных свойств на моей модели, это была проблема с моим Javascript.
Я делал некоторое спасение Ajax, где я перестраивал модель для отправки обратно на сервер. Когда я сначала инициализировал страницу, я установил свою исходную модель в переменную:
My result.Data имеет свойство: result.Data.Items
Итак, через некоторое время я кое-что делаю и хочу сэкономить через Ajax. Часть процесса состоит в том, чтобы захватить массив из некоторого побочного процесса и установить его в мое свойство currentModel.Items и отправить currentModel на сервер.
В моем Javascript, однако, я сделал это, вместо этого:
Я не поймал его, но в Visual Studio он автоматически запустит первую букву для свойств Javascript (это тоже может быть ReSharper). Затем я получил точную ошибку, отправленную OP при попытке сохранить, поскольку currentModel теперь имеет currentModel.Items И currentModel.Items
Простая замена “пунктов” на “Элементы” устраняет проблему.
У меня была такая же проблема. Он появился для меня после перехода на MVC 5 из MVC 3.
У меня был пользовательский шаблон редактора и ему пришлось использовать его так:
Чтобы решить проблему, мне пришлось удалить проходящий объект ViewData . Поэтому в конце я имел:
Надеюсь, что это поможет.
У меня была такая же ошибка. И после того, как я уже думал, что мой ум сломан, потому что я переименовал почти все свойства моих моделей, решение было удалить одну ссылку на All Syncfusion Controls и добавить ссылки на отдельные элементы управления этого элемента управления. (От Nuget)
В моем случае корень проблемы был двойным именем свойства в клиенте json, который отличался только чувствительностью к регистру.
Другой способ встретить эту ошибку – из набора данных с неназванными столбцами. Ошибка генерируется, когда набор данных сериализуется в JSON.
Это утверждение приведет к ошибке:
Добавление имен столбцов предотвратит ошибку:
У меня была такая же ошибка, но б/с по разным причинам. Использование Entity Framework. Еще одна вещь, которую я должен добавить здесь, прежде чем я поделюсь своим кодом и решением, у меня была точка останова на методе контроллера, но он не ломался там, просто выдает исключение 500 внутренняя ошибка сервера.
Я отправлял данные из представления в контроллер через ajax (http post). Модель, которую я ожидал в качестве параметра, была классом. Это было унаследовано с другим классом.
Просто удалили дублированные поля из класса PurchaseOrder, и это сработало как прелесть.
В моем случае, просто когда вы компилируете код, он работает просто отлично. Но вызов одного из статического поля статического класса, имеющего словарь, как в примере кода, вызывает исключение.
Образец кода
Пояснение ADict имеет дважды добавленный ключ “test”. Итак, когда вы вызываете статический класс, он выдает исключение.
Источник
These C# examples show the ArgumentException being thrown. ArgumentOutOfRangeException and ArgumentNullException help validate arguments.
ArgumentException. A method can be called with invalid arguments.
An ArgumentException may be thrown in this case. Exceptions use derived types to indicate their meaning. But this does not give them extra abilities.
Note: Semantically, ArgumentException indicates that a method was called with an invalid argument.
Example. This method receives one formal parameter, a string type with the identifier «argument». In the method A, we perform two checks on the value of the variable argument, detecting when it is null or has zero characters in its buffer.
NullEmpty Strings
Constructor. When using the ArgumentNullException constructor, you can pass a string literal that is equal to the variable name that was null. This affects the debug output and will aid debugging.
Tip: You can use the same pattern on ArgumentException, which indicates a general argument-related exception.
Based on: .NET 4.5 C# program that uses ArgumentException using System; class Program { static void Main() { // Demonstrate the argument null exception. try { A(null); } catch (Exception ex) { Console.WriteLine(ex); } // Demonstrate the general argument exception. try { A(""); } catch (Exception ex) { Console.WriteLine(ex); } // Flow path without exception. Console.WriteLine(A("test")); } static int A(string argument) { // Handle null argument. if (argument == null) { throw new ArgumentNullException("argument"); } // Handle invalid argument. if (argument.Length == 0) { throw new ArgumentException("Zero-length string invalid", "argument"); } return argument.Length; } } Output: truncated System.ArgumentNullException: Value cannot be null. Parameter name: argument at Program.A(String argument)... System.ArgumentException: Zero-length string invalid Parameter name: argument at Program.A(String argument)... 4
An interesting part of this example. The parameter name, which is specified as the string literal in both exception constructors, is written to the output. The argument name is important as a debugging aid.
Example: Maybe the method A would receive two strings, and neither of them could be validly null—the argument name would be helpful.
Discussion. There are some cases where you should validate arguments with more care. If you have a method that is called in many different places or any external places written by external developers, then validating arguments is more important.
But: With an internal method, the arguments may not need to be carefully validated because they may never be invalid.
So: For truly performance-critical methods, do not validate arguments in most cases.
ArgumentNullException is thrown by code that checks arguments for null and then throws it explicitly. Usually, the method would fail with a NullReferenceException if the check was removed. Here, we use null on the Dictionary indexer.
DictionaryIndexer
And: The indexer compiles to the get_Item method. Internally, get_Item eventually uses the statement «throw new ArgumentNullException».
C# program that causes ArgumentNullException using System.Collections.Generic; class Program { static void Main() { var dictionary = new Dictionary<string, int>(); int value = dictionary[null]; } } Output Unhandled Exception: System.ArgumentNullException: Value cannot be null. Parameter name: key
User code. The ArgumentNullException can be understood as an exception that is thrown by user code, not the runtime. It thus represents an error that was carefully added to help the users of the library better understand what is wrong.
Tip: In many cases, avoiding the null check and allowing the runtime itself to detect a NullReferenceException would be faster.
ArgumentOutOfRangeException. This program causes an ArgumentOutOfRangeException to be thrown by the Substring method. The Substring method requires its argument to be greater than or equal to zero. In this program, this requirement is not met.
Substring
Tip: Internally, Substring checks its argument for a negative value. With this exception, it alerts you to an invalid value.
And: This error is helpful. It makes your program easier to fix. It pinpoints the nature of your logical error.
C# program that causes ArgumentOutOfRangeException class Program { static void Main() { string value = "test".Substring(-1); } } Output Unhandled Exception: System.ArgumentOutOfRangeException: StartIndex cannot be less than zero. Parameter name: startIndex
In this example, the ArgumentOutOfRangeException is thrown explicitly, with a throw statement, not by the runtime. This makes it useful because it indicates a specific cause of what happened. The message helps you pinpoint the cause.
Throw
Summary. We looked at the ArgumentException and ArgumentNullException types. In the exception type hierarchy, the type names are a way to encode the meaning of the exception’s cause. These exceptions indicate an argument problem.
Review: The ArgumentException and ArgumentNullException types are semantically rich and aid in efficient debugging.
Related Links
Adjectives
Ado
Ai
Android
Angular
Antonyms
Apache
Articles
Asp
Autocad
Automata
Aws
Azure
Basic
Binary
Bitcoin
Blockchain
C
Cassandra
Change
Coa
Computer
Control
Cpp
Create
Creating
C-Sharp
Cyber
Daa
Data
Dbms
Deletion
Devops
Difference
Discrete
Es6
Ethical
Examples
Features
Firebase
Flutter
Fs
Git
Go
Hbase
History
Hive
Hiveql
How
Html
Idioms
Insertion
Installing
Ios
Java
Joomla
Js
Kafka
Kali
Laravel
Logical
Machine
Matlab
Matrix
Mongodb
Mysql
One
Opencv
Oracle
Ordering
Os
Pandas
Php
Pig
Pl
Postgresql
Powershell
Prepositions
Program
Python
React
Ruby
Scala
Selecting
Selenium
Sentence
Seo
Sharepoint
Software
Spellings
Spotting
Spring
Sql
Sqlite
Sqoop
Svn
Swift
Synonyms
Talend
Testng
Types
Uml
Unity
Vbnet
Verbal
Webdriver
What
Wpf