0

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?

Uwe Keim
  • 39,551
  • 56
  • 175
  • 291
Pawel_J
  • 31
  • 7
  • 2
    This question either too broad or opinion based. You'll find plenty of guidance [here](http://ericlippert.com/category/exception-handling/), [here](http://www.hanselman.com/blog/GoodExceptionManagementRulesOfThumb.aspx) and [here](https://msdn.microsoft.com/en-us/library/seyhszts(v=vs.110).aspx) – rene Sep 23 '15 at 12:23
  • I think this question is probably going to get closed for being too open ended / opinion based. I personally would not throw an exception if you're simply reading values from a database. Write to an error log for sure, but in my opinion exceptions are more for "really bad" things that need to be handled differently by the application logic. If you're just telling your user, 'Hey dummy, this HTML is invalid' I don't really see the point. If you're parsing HTML and displaying it in a WebViewer control then maybe. – sab669 Sep 23 '15 at 12:26
  • Rule of thumb: Exceptions are for developers, *not* users. Users should get a nice report if something went wrong. Developers need facts and as much technical information as possible to locate and fix a bug. – Corak Sep 23 '15 at 12:35
  • 1
    Don't inherit from `ApplicationException`, instead just inherit from `Exception` if you do create custom exceptions. – juharr Sep 23 '15 at 12:40

1 Answers1

1

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

Francisco Goldenstein
  • 13,299
  • 7
  • 58
  • 74