[Interest] Args

Philippe philwave at gmail.com
Mon May 8 12:16:57 CEST 2017


>>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.knoll at gmail.com> wrote:

> 
> > Am 08.05.2017 um 01:48 schrieb Igor Mironchik <igor.mironchik at 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 at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest





More information about the Interest mailing list