Latest toolkit version & Exceptions

Hi !

This time, I do not come with a problem, only with some questions :slight_smile:

I’ve noticed that since I begun to use one of the latest toolkit version (got it from the svn repo, on monday, I think) there has been a change in how the exceptions are handled by the toolkit.

In the former versions, an unhandled runtime exception was left untouched, and finally was written in the web server output log.
While not very explicit for the user, I think that that was quite a good thing in itself: in my book, runtime exceptions are coding exceptions - the kind of where you do not want your application to continue to work afterward (or, at least, not without a word ^^).

In the latest version I got, those exceptions seems to be handled by the toolkit. When I click on a button that throw a runtime exception (and that do happen quite frequently :p), I’ve got a nice red exclamation mark… but not any stacktrace :frowning: That make debugging quite a lot harder - and I really, really don’t want to have to surround all and every button listener by a " catch (Throwable e) " ^^

So, my question, at last !
Is that behavior a bug, or an undocumented feature ? :stuck_out_tongue:
And if it is a feature, is there a way to shut it off, for debugging purposes ?

Thank you,
Quentin.

Here is the issue that relates most likely to your question. We wanted to make these changes before stable version is released:
http://dev.itmill.com/ticket/2006
http://dev.itmill.com/changeset/5281

Well, Artur should answer to this question, I know he has made the changes you are interested of.

You might also consider adding below code to your application class, I haven’t yet checked if Artur has added any other nice features to handle errors in his [5281]
changeset…


/**
	 * Example how to catch terminal errors and change default behaviour of
	 * error reporting.
	 */
	@Override
	public void terminalError(Terminal.ErrorEvent event) {
		// Print errors always to standard errors streams too
		System.err.println("Terminal error:");
		event.getThrowable().printStackTrace();
		// And let them fall to GUI too (default)
		super.terminalError(event);
	}

PS. Sorry but our dev.itmill.com seems to be very slow ATM, people are investigating this issue as we speak… I think it’s time to purchase some new cool hardware because of the added service load :slight_smile:

I assume someone should review error handling changeset (if not yet done?) and make sure that every possible error is catchable by the Toolkit application developer.

IMO the worst case is that some error is just eaten (ignored), next worst case is that Toolkit just spits the error somewhere (standard error stream) and developer cannot participate handling this error in any way.

I hope Toolkit contains some mechanism that Toolkit application developer may catch all exceptions which are virtually possible e.g through following method:


// Override this method in your own Application
@override
public void exception(Exception exception) 

Artur, is this possible? If not then could you describe why Toolkit would not work this way?

We got all kind of exceptions happening deeply in Toolkit code, why not allowing developers to catch them all? Default behaviour is that Toolkit just throws them if developer does not override Application.exception method.

From the changeset I noticed that you throw various exceptions that are not possible to catch in Toolkit applications, am I right?

Good news, (I think)

Code below should catch “all” errors, now you got single point error handler where you can do what you wish.


/**
 	 * Example how to catch terminal errors and change default behaviour of
 	 * error reporting.
 	 */
 	@Override
 	public void terminalError(Terminal.ErrorEvent event) {
 		// Print errors always to standard errors streams too
 		System.err.println("Terminal error:");
 		event.getThrowable().printStackTrace();
 		// And let them fall to GUI too (default)
 		super.terminalError(event);
 	}

If you are still not content, please hit your thoughts to forums!

Wow, that seems very good indeed :smiley:

As soon as my databases servers are up again, I’ll test that terminalError() and post my thought on it - but it does seem to be everything I ever wanted, and more :smiley:

Thanks !

Quentin.