One question regarding vert.x and uncaught exceptions

[Wiktor Sierociński]

Hi,

My name is Wiktor and I am currently involved in project which is using vert.x to implement one of server services. 

Generally, everything look quite nice (Good job btw). But, I have one concern related to uncaught exceptions. I was developing backends in node.js and there any uncaught exception leads to crash of the server and thread involved because there is just one thread. It is in my opinion valid behaviour because any uncaught exception can potentially lead to some unexpected future behaviours of the server. Such method also is consistent with the mantra "let it crash" - popular in Erlang or other actor-like model systems. 

My question is: how vert.x is dealing with "uncaught exceptions"? As far as I see it is just swallowing them and Verticles are not being restarted/crashed. For example when there is exception being thrown in the handler of some SQL query then request which has initiated this query is lost in the state of being "idle". Is it true?

I am wondering could it be potentially dangerous behaviour because I think that such uncaught exceptions can lead to lack of deallocation of some resources. 

Best regards,
Wiktor Sierociński

[Thomas SEGISMONT]

Vert.x lets you register exceptionHandlers at the global level or the context level. So the uncaught exception recovery policy is up to you.

--
You received this message because you are subscribed to the Google Groups "vert.x" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vertx+unsubscribe@googlegroups.com.
Visit this group at https://groups.google.com/group/vertx.
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/84399f36-f3d0-4da4-8f77-b3c28d040aa6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[javadevmtl]

How do you do that?

On Thursday, 9 February 2017 09:39:52 UTC-5, Thomas Segismont wrote:

Vert.x lets you register exceptionHandlers at the global level or the context level. So the uncaught exception recovery policy is up to you.

2017-02-09 12:27 GMT+01:00 Wiktor Sierociński <w.sier...@gmail.com>:

Hi,

My name is Wiktor and I am currently involved in project which is using vert.x to implement one of server services. 

Generally, everything look quite nice (Good job btw). But, I have one concern related to uncaught exceptions. I was developing backends in node.js and there any uncaught exception leads to crash of the server and thread involved because there is just one thread. It is in my opinion valid behaviour because any uncaught exception can potentially lead to some unexpected future behaviours of the server. Such method also is consistent with the mantra "let it crash" - popular in Erlang or other actor-like model systems. 

My question is: how vert.x is dealing with "uncaught exceptions"? As far as I see it is just swallowing them and Verticles are not being restarted/crashed. For example when there is exception being thrown in the handler of some SQL query then request which has initiated this query is lost in the state of being "idle". Is it true?

I am wondering could it be potentially dangerous behaviour because I think that such uncaught exceptions can lead to lack of deallocation of some resources. 

Best regards,
Wiktor Sierociński

--
You received this message because you are subscribed to the Google Groups "vert.x" group.

To unsubscribe from this group and stop receiving emails from it, send an email to vertx+un...@googlegroups.com.

[Wiktor Sierociński]

Thomas Segismont:

I tried to add handler to "vertx.exceptionHandler" but it did not catch exceptions I described above (in this case: thrown in handler of SQL query).
Like here:

connection.queryWithParams(query, params, queryRes -> {
  -> thrown here
})

That is why I am concerned that some other exceptions would not be catched too.

[Thomas SEGISMONT]

With Vertx#exceptionHandler and Context#exceptionHandler

To unsubscribe from this group and stop receiving emails from it, send an email to vertx+unsubscribe@googlegroups.com.

Visit this group at https://groups.google.com/group/vertx.

To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/f0a91c97-1370-4d8c-a883-b422d578bd5f%40googlegroups.com.

[Thomas SEGISMONT]

Could you put up a small reproducer on GitHub?

--

You received this message because you are subscribed to the Google Groups "vert.x" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vertx+unsubscribe@googlegroups.com.
Visit this group at https://groups.google.com/group/vertx.

To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/17caf20a-5ad5-469d-a4e3-da1e4423ff97%40googlegroups.com.

[Wiktor Sierociński]

I have added small gist, please check it out: https://gist.github.com/wsieroci/953a3592eec3f2443e6a24ff5b826d5a

On Thursday, February 9, 2017 at 5:11:30 PM UTC+1, Thomas Segismont wrote:

Could you put up a small reproducer on GitHub?

2017-02-09 16:35 GMT+01:00 Wiktor Sierociński <w.sier...@gmail.com>:

Thomas Segismont:

I tried to add handler to "vertx.exceptionHandler" but it did not catch exceptions I described above (in this case: thrown in handler of SQL query).
Like here:

connection.queryWithParams(query, params, queryRes -> {
  -> thrown here
})

That is why I am concerned that some other exceptions would not be catched too.

On Thursday, February 9, 2017 at 12:27:37 PM UTC+1, Wiktor Sierociński wrote:

Hi,

My name is Wiktor and I am currently involved in project which is using vert.x to implement one of server services. 

Generally, everything look quite nice (Good job btw). But, I have one concern related to uncaught exceptions. I was developing backends in node.js and there any uncaught exception leads to crash of the server and thread involved because there is just one thread. It is in my opinion valid behaviour because any uncaught exception can potentially lead to some unexpected future behaviours of the server. Such method also is consistent with the mantra "let it crash" - popular in Erlang or other actor-like model systems. 

My question is: how vert.x is dealing with "uncaught exceptions"? As far as I see it is just swallowing them and Verticles are not being restarted/crashed. For example when there is exception being thrown in the handler of some SQL query then request which has initiated this query is lost in the state of being "idle". Is it true?

I am wondering could it be potentially dangerous behaviour because I think that such uncaught exceptions can lead to lack of deallocation of some resources. 

Best regards,
Wiktor Sierociński

--
You received this message because you are subscribed to the Google Groups "vert.x" group.

To unsubscribe from this group and stop receiving emails from it, send an email to vertx+un...@googlegroups.com.

Visit this group at https://groups.google.com/group/vertx.

[Thomas SEGISMONT]

I tried with 3.3.3 and 3.4.0.Beta1 and it works for me. If you create a complete project I could try to reproduce.

To unsubscribe from this group and stop receiving emails from it, send an email to vertx+unsubscribe@googlegroups.com.

Visit this group at https://groups.google.com/group/vertx.

To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/96a3ca87-80de-4375-816d-63c19021d713%40googlegroups.com.

[Alexander Lehmann]

I guess the sql implementation has its own Context and that is not the same as the context of your verticle. When throwing an exception in the verticle directly, you are on the right context and the exception reaches the handler.

[Alexander Lehmann]

I think you are right, the exception handler that is used in VertxEventLoopExecutionContext just logs the exception and does not pass it anywhere.
Maybe there would be an exception handler necessary in the AsyncSQLClient interface.

Regardless, could you please post a complete reproducer project so we can check the issue further.

[Wiktor Sierociński]

I have prepared github repo: https://github.com/wsieroci/vertx-sample

[Thomas SEGISMONT]

The problem comes from the async driver. It uses VertxEventLoopExecutionContext#create extensively. This facility is used to bridge the Scala world with the Vert.x world. But for some reason it has its own failure reporter, instead of using the Vert.x context exception handler. Would you mind to create an issue in the AsyncDriver? I'll ask Clément to have a look since he created this class. Thanks

To unsubscribe from this group and stop receiving emails from it, send an email to vertx+unsubscribe@googlegroups.com.

Visit this group at https://groups.google.com/group/vertx.

To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/48a293b4-f688-4a14-bddb-06acb5113f80%40googlegroups.com.

[Alexander Lehmann]

I took a look at the issue yesterday (thanks to Wiktor for the reproducer) and I thought the context is always created with create(vertx) and not with create(vertx, handler), so that the default error handler is used which just logs the exception.

[Wiktor Sierociński]

Where exactly I am supposed to create an issue?

On Monday, February 13, 2017 at 11:42:15 AM UTC+1, Thomas Segismont wrote:

[Thomas SEGISMONT]

On GitHub https://github.com/vert-x3/vertx-mysql-postgresql-client/issues

To unsubscribe from this group and stop receiving emails from it, send an email to vertx+unsubscribe@googlegroups.com.

Visit this group at https://groups.google.com/group/vertx.

To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/67bab477-33cd-4a10-ab86-f9bde57c8ae7%40googlegroups.com.

[Thomas SEGISMONT]

PR sent https://github.com/vert-x3/vertx-mysql-postgresql-client/pull/68