\r\n \r\n Blog
\r\n- \r\n {BlogPostsIndex.map((post: BlogPostIndexItem) => \r\n
\r\n
\r\n {this.props.title}
\r\n{this.formatDate(this.props.date)}
\r\n \r\n\r\n\r\n\r\n
\r\n\r\n The ArgumentException (and its derived types) are probably[1] the most commonly thrown exceptions in .NET after Exception itself, but they're often used incorrectly, and the MDSN guidelines are somewhat vague.\r\n\r\n
\r\n There are three types of ArgumentException in .NET; the ArgumentException itself and its two derived types ArgumentNullException and ArgumentOutOfRangeException. Let's explore.\r\n\r\n \r\n\r\n \r\n The ArgumentNullException is usually thrown right at the start of a method, as part of a precondition check. If possible, parameters should be checked in signature order to aid discoverability and debugging.\r\n
\r\n A less common use for the ArgumentNullException is to notify the caller when a method was just about to call into another method with a null argument, generated from a caller-provided parameter. The caveat of course being that you need to know somehow that it's invalid to pass null to the inner method. But if you can guarantee this, you benefit from being able to throw earlier, and with a more meaningful message.\r\n\r\n\r\n \r\n\r\n\r\n
\r\n\r\n
\r\n\r\n\r\n The ArgumentOutOfRangeException should be thrown whenever a parameter is not null, but still out of the range of acceptable values. A constructor that takes a string message should always be used, and include a description of the valid range of values.\r\n
\r\n Like the ArgumentNullException, when calling the single string constructor the parameter name should be passed in, and the created exception will have the friendly message \r\n\r\n \r\n ArgumentException is the concrete base class of the other two. It should only be used when one of the more specific types are not appropriate, which is usually when two or more arguments are not compatible with each other.\r\n
\r\n
It should not be used with a single string parameter denoting a parameter name (e.g. \r\n
\r\n
\r\n
\r\n
\r\n
\r\n\r\n\r\n\r\n [1] At least according to GitHub: Exception has 4.3m usages, ArgumentException (all varieties) has 1.84m, InvalidOperationException has 460k.\r\n
\r\n [2] The Main method signature being the obvious exception.\r\n \r\n\r\n\r\n
\r\n );\r\n }\r\n\r\n public static nlogQuickStart() {\r\n return (\r\n ArgumentException Best Practices
\r\n 30 Jun 2015\r\n\r\n
\r\n There are three types of ArgumentException in .NET; the ArgumentException itself and its two derived types ArgumentNullException and ArgumentOutOfRangeException. Let's explore.\r\n\r\n
ArgumentNullException
\r\n\r\n A less common use for the ArgumentNullException is to notify the caller when a method was just about to call into another method with a null argument, generated from a caller-provided parameter. The caveat of course being that you need to know somehow that it's invalid to pass null to the inner method. But if you can guarantee this, you benefit from being able to throw earlier, and with a more meaningful message.\r\n\r\n\r\n
\r\n\r\n
\r\n
\r\n Argument vs. Parameter
\r\n \r\n The generally accepted convention which .NET follows[2] is to call the things being passed into a method the arguments, and the things within a method parameters.\r\n
\r\n \r\n\r\n
ArgumentOutOfRangeException
\r\n\r\n Like the ArgumentNullException, when calling the single string constructor the parameter name should be passed in, and the created exception will have the friendly message
"Specified argument was out of the range of valid values. Parameter name: foo".\r\n ArgumentException
\r\n\r\n
It should not be used with a single string parameter denoting a parameter name (e.g.
throw new ArgumentException("foo")), as this violates the signature (public ArgumentException(string message)), by providing no message with details of the issue.\r\n\r\n\r\n \r\n
\r\n
\r\n
\r\n
\r\n\r\n\r\n
\r\n [2] The Main method signature being the obvious exception.\r\n
\r\n
\r\n\r\n It's powerful, actively developed, has decent documentation, a wide user base and supports Silverlight and Windows Phone. It might take an extra 5 minutes setting up the base config, but it's worth it. \r\n \r\n \r\n \r\n\r\n
\r\n\r\n\r\n \r\n\r\n
\r\n
\r\n
\r\n\r\n
\r\n );\r\n }\r\n};\r\n","import * as React from 'react';\r\nimport { connect } from 'react-redux';\r\nimport { RouteComponentProps } from 'react-router';\r\nimport { HtmlPostRepo } from \"./HtmlPostRepo\";\r\n\r\nimport Prism from \"prismjs\";\r\nimport \"prismjs/components/prism-csharp\";\r\nimport ReactMarkdown from 'react-markdown';\r\n\r\n\r\ntype BlogPostCardProps = {\r\n title: string,\r\n description: string,\r\n date: Date,\r\n}\r\n\r\ntype MarkdownState = {\r\n markdown: string\r\n}\r\n\r\nclass BlogPost extends React.ComponentNLog (really) quick start
\r\n 23 May 2015\r\n\r\n
Why NLog?
\r\n3 Step Setup
\r\n\r\n- \r\n \r\n
- 1. Install using NuGet \r\n
- 2. Add the following to your App.config inside the
<configuration>element \r\n\r\n 3. Now all you have to do is get the Logger object and log from it
\r\n\r\n{`Logger _logger = LogManager.GetLogger(\"log\");\r\n_logger.Error(\"Foo\");\r\n_logger.Info(\"Bar\");\r\n// etc...`}
\r\n
\r\n \r\n \r\n \r\n
\r\n \r\n{`\r\n \r\n \r\n\r\n\r\n \r\n \r\n \r\n \r\n \r\n \r\n `}\r\n \r\n \r\n \r\n \r\n\r\n
\r\n
\r\n Exception: \"Only one <configSections> element allowed per config file and if present must be the first child of the root\"
\r\n \r\n\r\n If you get this exception, make sure the
\r\n <configsection> is at the top of the file, just under <configuration>.\r\n \r\n\r\n This config is set up to create a log file at
C:/Temp/log.txt, and append to it. As this just creates one ever expanding file, it's only really useful for debugging. See instructions below on configuring NLog to create a new timestamped log file on each application launch.\r\n \r\n\r\n
Optional Config
\r\n- \r\n
- \r\n
\r\n \r\nFresh log file per application launch, named by creation timestamp
\r\n
\r\n{``} \r\n\r\n - \r\n
\r\n \r\nException support with stacktrace (also note the bonus
\r\n{\"${longdate}\"}to get timestamped log lines)
\r\n{\"\r\n\"}\r\n
\r\n\r\n{`Exception e = ...\r\n_logger.Error(\"Uh oh: \", e);`}\r\n - \r\n
\r\n \r\nLog to
\r\n%AppData%/YourAppName(no need to create this beforehand)
\r\n{\"\r\n\"}\r\n \r\n - \r\n
\r\n \r\nSpecify minimum logging level of warning
\r\n
\r\n<logger name=\"log\" writeTo=\"log\" minlevel=\"Warning\"/>\r\n - \r\n
\r\n \r\nClass specific config
\r\n
\r\n\r\n{`\r\n\r\n\r\n `}\r\n
\r\n\r\nLogger _logger = LogManager.GetCurrentClassLogger();\r\n\r\n - \r\n
\r\n \r\nEnable Visual Studio intellisense
\r\n Download\r\nhttp://www.nlog-project.org/schemas/NLog.xsdsomewhere (\r\nC:\\Program Files (x86)\\Microsoft Visual Studio 12.0\\Xml\\Schemasis a good place). \r\n Go to App.config properties -> Schemas -> Add NLog.xsd.\r\n \r\n
\r\n\r\n
Putting it all together
\r\n\r\n{`\r\n \r\n \r\n \r\n\r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n `}Dependency bundling
\r\n If you're using a dependency bundler such as Fody/Costura you'll need to define the config programatically on startup:\r\n
\r\n{`var config = new LoggingConfiguration();\r\n\r\nvar target = new FileTarget();\r\ntarget.Name = \"log\";\r\ntarget.FileName = @\"\\${specialfolder:folder=ApplicationData}/YourAppName/log_\\${cached:\\${longdate}:cached=true}.txt\";\r\ntarget.Layout = @\"\\${longdate} \\${message} \\${exception:format=tostring}\";\r\nconfig.AddTarget(\"log\", target);\r\n\r\nvar rule = new LoggingRule(\"*\", LogLevel.Trace, target);\r\nconfig.LoggingRules.Add(rule);\r\n\r\nLogManager.Configuration = config;`}\r\n \r\n
More @ Github docs
\r\n\r\n\r\n