I'm writing a program to process BibTeX files to HTML code. The program allows a user selection which fields will be processed or how to format output HTML code.
BibTeX files are text databases. My program reads BibTeX files and writes to convenient object format, and use this objects to generate HTML. If there is any syntax error, my program catches it.
And my question is: should I write an exception (inherited from System.AplicationException), throw it and then catch it to "ErrorLog" which will be visible to a user?
Or maybe I should write "ErrorLog" without exceptions - only on my own non-standard error objects? Which solution will be more elegant and consistent with good practice in C# programing?
It depends on the type of exception and the context. As a general rule (it has its "exceptions" of course), you should handle it with a try-catch if the situation is exceptional and you cannot protect yourself from it in advance.
If you are reading a file accross the network and the network fails while you are in the middle of the process, you'll get an exception and it's fine, you catch it, notify the user and make a decision either to retry, start again or stop. It makes no sense to check if the network is working every time you read a byte.
On the other hand, you should not use exceptions to handle the flow of your application. If you want to read a file, you can check if the file exists first and then start reading it. You could try to read it and catch and exception but it's not so clean. Also, take into account that creating exception has a cost because you need to create a big object with many, many properties like the stack trace.
In my opinion, parsin a syntax error is not an exceptional situation, you can find it, log it if you want, and show a message to the user indicating what happened. The method that parses the expressions should return a Result object that indicates if there were errors and, if any, the list of errors.
Read this article from Microsoft: Best Practices for Exceptions