On 4 August 2014 13:44, Dicebot via Digitalmars-d < [email protected]> wrote:
> On Monday, 4 August 2014 at 03:15:32 UTC, Manu via Digitalmars-d wrote: > >> Well, then they're not particularly useful in practise. I'm finding that I >> can rarely blanket an operation across all exceptions. >> The nature of exceptions is that they are of a particular type, so why >> have >> no access to that concept when trying to respond to them... >> > > You may have coding style particularly alien to scope guards :) Those are > very convenient to use as a simple an generic alternative to RAII, > especially when interfacing with C libraries. Sure, scope() may be useful for this, but it seems in my experience that destructors almost always perform this without any additional code at the callsite. C libraries are exactly the only case where I've managed to use scope() successfully. This seems like a waste. A key talking point of the language finds use almost exclusively when used in conjunction with another language... :/ I find that most often one wants to catch majority of exceptions only in > somewhat high level parts of code (i.e. main loop) and rest is just cleanup > code - perfect fit for scope guards. > I can't think of many instances where I would want to catch an exception at the main loop unless it was completely unexpected, like out of memory or something. Almost all exceptions I throw are in relation to bad input data, and they are to be caught at a slightly higher level of input processing. My code has become try/catch-tastic, and I really don't like looking at it. It rather sickens me and reminds me of Java, and I'm strongly tempted to just abandon my experiment and return to C-style error handling with sentinel values. So... why not make scope guards more useful? It wouldn't be hard. scope(failure, MyException e) is completely non-destructive, and adds significant power to the concept. scope(success) is probably one I don't see use case case for though > Yeah, I can't imagine a use for it either.
