Jump to page: 1 2
Thread overview
Scope failure is not preventing application crush in case of uncaught exceptions
Dec 16
ketmar
Dec 16
ketmar
OT: s/crush/crash/g
December 16
While calling this function :

bool PublicMarketCall( ref Json result )
{
  string fullUrl = "https://bittrex.com/api/v1.1/public/getmarketsummaries";
  Json data;
  try
  {
  	requestHTTP(fullUrl,
  		(scope req) {
  			req.method = HTTPMethod.GET;
  		},
  		(scope res) {
  			data = parseJsonString(res.bodyReader.readAllUTF8());	
  		}
  	);
  }
  catch ( std.json.JSONException e )
  {
  	writeln("Exception was caught while making the public call: ", fullUrl);
  	return false;
  }

  scope(failure)
  	writeln("Exception was caught while public data: ", fullUrl);
  return false;
}

Very rarely (I am calling this function thousands of times in a day) like once in a day I am getting a crush while calling requestHTTP function :

object.Exception@../../../.dub/packages/vibe-d-0.8.1/vibe-d/core/vibe/core/drivers/libevent2.d(375): Failed to connect to host 104.17.154.108:443: 7FF703F4F617
----------------
??:? [0x606cee]
??:? [0x60ceb2]
exception.d:421 [0x4644a3]
exception.d:388 [0x41396d]
libevent2.d:375 [0x59002b]
net.d:129 [0x5be726]
client.d:610 [0x4a8ed4]
client.d:528 [0x4a7224]
client.d:462 [0x4a5a3f]
client.d:157 [0x4a5819]
client.d:133 [0x4a52bf]
.... --> Some files belonging my function
app.d:41 [0x43b947]
??:? [0x612f3e]
??:? [0x612efd]
??:? [0x612df8]
__entrypoint.d:8 [0x43be54]
??:? __libc_start_main [0x3de282f]
??:? [0x406fb8]
Program exited with code 1

As far as I know scope(failure) should be collecting all failure cases. And my application shouldn't crush with uncaught exceptions. What I am missing?




December 16
kerdemdemir wrote:

> As far as I know scope(failure) should be collecting all failure cases.

nope. `failure` scope won't stop exception propagation, it is just called before exception leaves your function, to give you a last chance to do some immediate cleanup.
December 16
On Saturday, 16 December 2017 at 20:56:26 UTC, ketmar wrote:
> kerdemdemir wrote:
>
>> As far as I know scope(failure) should be collecting all failure cases.
>
> nope. `failure` scope won't stop exception propagation, it is just called before exception leaves your function, to give you a last chance to do some immediate cleanup.

Than do I still need to catch'em all? For me it doesn't matter the which exception it is. It is more important for me to not pollute my code with so many exception related lines. What is the most compact way for me to catch'em all?
December 16
kerdemdemir wrote:

> On Saturday, 16 December 2017 at 20:56:26 UTC, ketmar wrote:
>> kerdemdemir wrote:
>>
>>> As far as I know scope(failure) should be collecting all failure cases.
>>
>> nope. `failure` scope won't stop exception propagation, it is just called before exception leaves your function, to give you a last chance to do some immediate cleanup.
>
> Than do I still need to catch'em all? For me it doesn't matter the which exception it is. It is more important for me to not pollute my code with so many exception related lines. What is the most compact way for me to catch'em all?

see collectException[0], for example. something like (WARNING! DON'T DO THIS! it's not wise to silence everything! try to be selective with `collectException!RequiredExceptionType` instead!)

	collectException(() {
		your code here
	}());

or just move your code to some function, and do

	collectException(myfunction);


[0] http://dpldocs.info/experimental-docs/std.exception.collectException.2.html
December 16
On Saturday, December 16, 2017 21:22:47 kerdemdemir via Digitalmars-d-learn wrote:
> On Saturday, 16 December 2017 at 20:56:26 UTC, ketmar wrote:
> > kerdemdemir wrote:
> >> As far as I know scope(failure) should be collecting all
> >> failure cases.
> >
> > nope. `failure` scope won't stop exception propagation, it is just called before exception leaves your function, to give you a last chance to do some immediate cleanup.
>
> Than do I still need to catch'em all? For me it doesn't matter the which exception it is. It is more important for me to not pollute my code with so many exception related lines. What is the most compact way for me to catch'em all?

The only way to catch an exception is with a catch block, and if you do

catch(Exception e)

then it will catch all exceptions derived from Exception (which is everything that isn't an Error, though catching Errors is almost always a bad idea).

You can also use something like std.exception.catchException like Ketmar suggests, though that's just using a catch internally and returning the Exception. There's nothing magical about it.

In general though, just eating exceptions is likely to cause problems. If an exception is thrown, it's because there's a problem, and your program should either be responding to it or exiting. Usually, you put try-catch statements at the points in your program that are best suited for handling whatever exceptions are likely to be thrown. If you feel the need to put tons of try-catch statements in your program, you're probably doing something wrong. Sometimes, lots of try-catch statements is appropriate, but usually, you shouldn't need very many.

See Also:

http://ddili.org/ders/d.en/exceptions.html http://ddili.org/ders/d.en/scope.html

- Jonathan M Davis

December 17
On Saturday, 16 December 2017 at 21:56:49 UTC, Jonathan M Davis wrote:
> The only way to catch an exception is with a catch block, and if you do

If you return inside a scopeguard though, the exception (or error!) is swallowed. https://run.dlang.io/is/GEtQ6D

void main()
{
    foo();
    writeln("no error!");
}

int foo()
{
    scope(failure) return -1;
    assert(0);
}
December 16
On Sunday, December 17, 2017 00:10:27 Anonymouse via Digitalmars-d-learn wrote:
> On Saturday, 16 December 2017 at 21:56:49 UTC, Jonathan M Davis
>
> wrote:
> > The only way to catch an exception is with a catch block, and if you do
>
> If you return inside a scopeguard though, the exception (or error!) is swallowed. https://run.dlang.io/is/GEtQ6D
>
> void main()
> {
>      foo();
>      writeln("no error!");
> }
>
> int foo()
> {
>      scope(failure) return -1;
>      assert(0);
> }

Which is arguably a bug. The problem stems from the fact that scope statements get lowered to try-catch-finally blocks. But the entire purposed of scope statements is to be able to do stuff while an exception is in flight, not to actually handle the exception or affect it in any way.

- Jonathan M Davis

December 16
On 12/16/2017 12:51 PM, kerdemdemir wrote:

> I am getting a crush while calling requestHTTP
> function :

That sounds like "having a crush", which happens to me too but I think you meant "crash". :o)

Ali

December 17
On Sunday, 17 December 2017 at 00:10:27 UTC, Anonymouse wrote:
> If you return inside a scopeguard though, the exception (or error!) is swallowed. https://run.dlang.io/is/GEtQ6D

The scope guard will not 'swallow' it, if you use -release mode.

Which suggests to me, that assert(0) operates differently when 'not' using -release mode.

My 'guess' is, that release mode issues a halt instruction, whereas in non-release mode it is just an exception like any other exception.

December 17
On Sunday, December 17, 2017 08:10:06 codephantom via Digitalmars-d-learn wrote:
> On Sunday, 17 December 2017 at 00:10:27 UTC, Anonymouse wrote:
> > If you return inside a scopeguard though, the exception (or error!) is swallowed. https://run.dlang.io/is/GEtQ6D
>
> The scope guard will not 'swallow' it, if you use -release mode.
>
> Which suggests to me, that assert(0) operates differently when
> 'not' using -release mode.
>
> My 'guess' is, that release mode issues a halt instruction, whereas in non-release mode it is just an exception like any other exception.

assert(0) does indeed turn into a HLT instruction in -release mode (as does any assertion that's known to be false at compile time). It's a special case intended for marking code that's supposed to be unreachable. Without -release, failed assertions throw AssertErrors, so they're Errors not Exceptions, though I think that scope statements currently catch and then rethrow Throwable rather than Exception, which is why AssertErrors would be affected.

- Jonathan M Davis

« First   ‹ Prev
1 2