>>There is probably a reason why completely new languages like Swift come >>completely without exception handling
Quote from Apple doc: "Swift provides first-class support for throwing, catching, propagating, and manipulating recoverable errors at runtime." https://developer.apple.com/library/content/documentation/Swift/Conceptual/Swift_Programming_Language/ErrorHandling.html Philippe On Mon, 8 May 2017 07:11:22 -0300 Till Oliver Knoll <till.oliver.kn...@gmail.com> wrote: > > > Am 08.05.2017 um 01:48 schrieb Igor Mironchik <igor.mironc...@gmail.com>: > > > > Hi, > >>>> Using exceptions in arguments parser is something that just cannot be > >>>> justified. > >>>> > >>> Why not? > >> Even in the danger of starting a huge debate about "exceptions vs return > >> error code" here are my thoughts about it: > >> > >> Exceptions should just be used for... well, /exceptional/ cases. > >> > >> So what would be an "exceptional case" for a command line parser then? > >> Certainly not wrongly provided arguments. Humans tend to misspell words > >> all the time, so that's "the norm": business as usual for a command line > >> parser to validate the input and inform the user appropriately (with a > >> usage help, similar spelled commands etc.). Nothing which cries > >> "exception!" here IMHO. > >> > >> The only thing I could think of in a 10 second brainstorming which could > >> be considered "exceptional" is when e.g. "stdin" (or some socket even from > >> which to read commands, but even this would be a bordercase, as it could > >> be considered "normal" that a socket cannot be opened) cannot be opened > >> for reading (which is somewhat a constructed example, as arguments are > >> usually passed as input parameters to main() anyway - but you get the > >> idea). > >> > >> The internet is full of articles - and opinions - about when to use > >> exceptions, and when not (and we haven't even touched the topic of > >> "unchecked vs checked exceptions" - at least in the Java camp that's all > >> the rage ;)). > > > > I will not start that holly war about what you said.... :) I just say that > > I will think about more and more user friendly messages on wrong user input. > > Hold on: the one (exceptions vs return error codes) has /nothing/ to do with > the other (user-friendly error messages). Just to be on the same page here... > > > I wanted to simplify a life of a developer and a user of console > > application. But developer will be informed about "errors" through the > > exceptions. > > Yes, your intentions were clear. But did you just read what I wrote about > /when/ to use exceptions? > > In fact, you're not - necessarily - simplifying "the life of a developer" by > using exceptions. Au contraire, you force them to use patterns like RAII > (which is mostly a good thing by itself), think about whether their code is > "exception-safe" etc. > > There is probably a reason why completely new languages like Swift come > completely without exception handling - which raises interesting questions > (pun intended), as the main "GUI framework" (Cocoa/ObjC based) still uses - > and throws - exceptions then and when... but that's yet another story ;) > > Cheers, > Oliver > _______________________________________________ > Interest mailing list > Interest@qt-project.org > http://lists.qt-project.org/mailman/listinfo/interest _______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
