Eclipse – Exception(s) when trying to debug a birt report

birtdebuggingeclipseexception

I want to debug the afterDataSetFilled method of a chart. When I start debugging, I am getting a dialog prompting me to enter the values of all the report parameters (two of which are datetime). No matter under which format I enter the datetime parameters, I always get the following exception:

SEVERE: Engine exception
org.eclipse.birt.report.engine.api.impl.ParameterValidationException: The type of parameter "startDate" is expected as "dateTime", not "java.lang.String".
    at org.eclipse.birt.report.engine.api.impl.EngineTask.validateParameterValueType(EngineTask.java:865)
    at org.eclipse.birt.report.engine.api.impl.EngineTask.validateAbstractScalarParameter(EngineTask.java:829)
    at org.eclipse.birt.report.engine.api.impl.EngineTask.access$0(EngineTask.java:756)
    at org.eclipse.birt.report.engine.api.impl.EngineTask$ParameterValidationVisitor.visitScalarParameter(EngineTask.java:686)
    at org.eclipse.birt.report.engine.api.impl.EngineTask$ParameterVisitor.visit(EngineTask.java:1400)
    at org.eclipse.birt.report.engine.api.impl.EngineTask.doValidateParameters(EngineTask.java:670)
    at org.eclipse.birt.report.engine.api.impl.RunAndRenderTask.doRun(RunAndRenderTask.java:94)
    at org.eclipse.birt.report.engine.api.impl.RunAndRenderTask.run(RunAndRenderTask.java:77)
    at org.eclipse.birt.report.debug.internal.core.launcher.ReportLauncher.createReport(ReportLauncher.java:594)
    at org.eclipse.birt.report.debug.internal.core.launcher.ReportLauncher.renderReport(ReportLauncher.java:541)
    at org.eclipse.birt.report.debug.internal.core.launcher.ReportLauncher.run(ReportLauncher.java:455)
    at org.eclipse.birt.report.debug.internal.core.launcher.ReportLauncher.main(ReportLauncher.java:104)
    at org.eclipse.birt.report.debug.internal.core.ReportDebugger.start(ReportDebugger.java:39)
    at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
    at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
    at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
    at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:369)
    at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:585)
    at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:619)
    at org.eclipse.equinox.launcher.Main.basicRun(Main.java:574)
    at org.eclipse.equinox.launcher.Main.run(Main.java:1407)
    at org.eclipse.equinox.launcher.Main.main(Main.java:1383)
May 10, 2011 10:08:11 AM org.eclipse.birt.report.debug.internal.core.vm.ReportVMServer$1 run
WARNING: [Server] client disconnected

I couldn't find what was wrong. The default values I entered (in the yyyy-MM-dd HH:mm:ss format) for the report parameters are ok, and the report is generated correctly. However, when starting the debugger they are entered under a different format (MMMM d, y h:mm:ss). If I leave them like that I get the exception. If I change them to the yyyy-MM-dd HH:mm:ss format I still get the exception. Is this a known BIRT issue, or am I doing something wrong?

I was able to bypass this issue by hard-coding these values within the SQL query (and removing the datetime report parameters). But after I did that, another exception appeared:

SEVERE: Engine exception
org.eclipse.birt.report.engine.api.EngineException: Failed to initialize emitter.
    at org.eclipse.birt.report.engine.emitter.EmitterUtil.getOuputStream(EmitterUtil.java:80)
    at org.eclipse.birt.report.engine.emitter.html.HTMLReportEmitter.initialize(HTMLReportEmitter.java:350)
    at org.eclipse.birt.report.engine.api.impl.EngineTask.initializeContentEmitter(EngineTask.java:2044)
    at org.eclipse.birt.report.engine.api.impl.RunAndRenderTask.doRun(RunAndRenderTask.java:117)
    at org.eclipse.birt.report.engine.api.impl.RunAndRenderTask.run(RunAndRenderTask.java:77)
    at org.eclipse.birt.report.debug.internal.core.launcher.ReportLauncher.createReport(ReportLauncher.java:594)
    at org.eclipse.birt.report.debug.internal.core.launcher.ReportLauncher.renderReport(ReportLauncher.java:541)
    at org.eclipse.birt.report.debug.internal.core.launcher.ReportLauncher.run(ReportLauncher.java:455)
    at org.eclipse.birt.report.debug.internal.core.launcher.ReportLauncher.main(ReportLauncher.java:104)
    at org.eclipse.birt.report.debug.internal.core.ReportDebugger.start(ReportDebugger.java:39)
    at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
    at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
    at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
    at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:369)
    at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:585)
    at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:619)
    at org.eclipse.equinox.launcher.Main.basicRun(Main.java:574)
    at org.eclipse.equinox.launcher.Main.run(Main.java:1407)
    at org.eclipse.equinox.launcher.Main.main(Main.java:1383)
Caused by: java.io.FileNotFoundException: /StandardOCE_PRS2_OperatorProductivity.rptdesign.html (Permission denied)
    at java.io.FileOutputStream.open(Native Method)
    at java.io.FileOutputStream.<init>(FileOutputStream.java:179)
    at java.io.FileOutputStream.<init>(FileOutputStream.java:131)
    at org.eclipse.birt.report.engine.emitter.EmitterUtil.getOuputStream(EmitterUtil.java:75)
    ... 22 more

Have you encountered this issue before? What do you suggest I do to fix it?

Best Answer

I did as suggested:

Changed to the standard 'Debug' perspective
Under the full 'Run' menu, opened 'Debug Configurations'

I changed the "Temp Folder" entry to a directory OUTSIDE my Windows User Account (ie something under the C-drive, say: C:\Temp\Birt). I created the specified directory.

Then Eclipse debugging worked.

Don't raise generic exceptions

Avoid raising a generic Exception. To catch it, you'll have to catch all other more specific exceptions that subclass it.

Problem 1: Hiding bugs

raise Exception('I know Python!') # Don't! If you catch, likely to hide bugs.

For example:

def demo_bad_catch():
    try:
        raise ValueError('Represents a hidden bug, do not catch this')
        raise Exception('This is the exception you expect to handle')
    except Exception as error:
        print('Caught this error: ' + repr(error))

>>> demo_bad_catch()
Caught this error: ValueError('Represents a hidden bug, do not catch this',)

Problem 2: Won't catch

And more specific catches won't catch the general exception:

def demo_no_catch():
    try:
        raise Exception('general exceptions not caught by specific handling')
    except ValueError as e:
        print('we will not catch exception: Exception')
 

>>> demo_no_catch()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 3, in demo_no_catch
Exception: general exceptions not caught by specific handling

Best Practices: `raise` statement

Instead, use the most specific Exception constructor that semantically fits your issue.

raise ValueError('A very specific bad thing happened')

which also handily allows an arbitrary number of arguments to be passed to the constructor:

raise ValueError('A very specific bad thing happened', 'foo', 'bar', 'baz')

These arguments are accessed by the args attribute on the Exception object. For example:

try:
    some_code_that_may_raise_our_value_error()
except ValueError as err:
    print(err.args)

prints

('message', 'foo', 'bar', 'baz')

In Python 2.5, an actual message attribute was added to BaseException in favor of encouraging users to subclass Exceptions and stop using args, but the introduction of message and the original deprecation of args has been retracted.

Best Practices: `except` clause

When inside an except clause, you might want to, for example, log that a specific type of error happened, and then re-raise. The best way to do this while preserving the stack trace is to use a bare raise statement. For example:

logger = logging.getLogger(__name__)

try:
    do_something_in_app_that_breaks_easily()
except AppError as error:
    logger.error(error)
    raise                 # just this!
    # raise AppError      # Don't do this, you'll lose the stack trace!

Don't modify your errors... but if you insist.

You can preserve the stacktrace (and error value) with sys.exc_info(), but this is way more error prone and has compatibility problems between Python 2 and 3, prefer to use a bare raise to re-raise.

To explain - the sys.exc_info() returns the type, value, and traceback.

type, value, traceback = sys.exc_info()

This is the syntax in Python 2 - note this is not compatible with Python 3:

raise AppError, error, sys.exc_info()[2] # avoid this.
# Equivalently, as error *is* the second object:
raise sys.exc_info()[0], sys.exc_info()[1], sys.exc_info()[2]

If you want to, you can modify what happens with your new raise - e.g. setting new args for the instance:

def error():
    raise ValueError('oops!')

def catch_error_modify_message():
    try:
        error()
    except ValueError:
        error_type, error_instance, traceback = sys.exc_info()
        error_instance.args = (error_instance.args[0] + ' <modification>',)
        raise error_type, error_instance, traceback

And we have preserved the whole traceback while modifying the args. Note that this is not a best practice and it is invalid syntax in Python 3 (making keeping compatibility much harder to work around).

>>> catch_error_modify_message()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 3, in catch_error_modify_message
  File "<stdin>", line 2, in error
ValueError: oops! <modification>

In Python 3:

raise error.with_traceback(sys.exc_info()[2])

Again: avoid manually manipulating tracebacks. It's less efficient and more error prone. And if you're using threading and sys.exc_info you may even get the wrong traceback (especially if you're using exception handling for control flow - which I'd personally tend to avoid.)

Python 3, Exception chaining

In Python 3, you can chain Exceptions, which preserve tracebacks:

raise RuntimeError('specific message') from error

Be aware:

this does allow changing the error type raised, and
this is not compatible with Python 2.

Deprecated Methods:

These can easily hide and even get into production code. You want to raise an exception, and doing them will raise an exception, but not the one intended!

Valid in Python 2, but not in Python 3 is the following:

raise ValueError, 'message' # Don't do this, it's deprecated!

Only valid in much older versions of Python (2.4 and lower), you may still see people raising strings:

raise 'message' # really really wrong. don't do this.

In all modern versions, this will actually raise a TypeError, because you're not raising a BaseException type. If you're not checking for the right exception and don't have a reviewer that's aware of the issue, it could get into production.

Example Usage

I raise Exceptions to warn consumers of my API if they're using it incorrectly:

def api_func(foo):
    '''foo should be either 'baz' or 'bar'. returns something very useful.'''
    if foo not in _ALLOWED_ARGS:
        raise ValueError('{foo} wrong, use "baz" or "bar"'.format(foo=repr(foo)))

Create your own error types when apropos

"I want to make an error on purpose, so that it would go into the except"

You can create your own error types, if you want to indicate something specific is wrong with your application, just subclass the appropriate point in the exception hierarchy:

class MyAppLookupError(LookupError):
    '''raise this when there's a lookup error for my app'''

and usage:

if important_key not in resource_dict and not ok_to_be_missing:
    raise MyAppLookupError('resource is missing, and that is not ok.')

Best Answer

Related Solutions

Javascript – How to debug Node.js applications

Python – Manually raising (throwing) an exception in Python

How do I manually throw/raise an exception in Python?