Home » Archived » M2M (model-to-model transformation) » [ATL] Safety of Model Transformations
[ATL] Safety of Model Transformations [message #17750] |
Thu, 22 February 2007 23:11 |
Eclipse User |
|
|
|
Originally posted by: irbull.cs.uvic.ca
For the final part of my PhD I am creating a graphical editor that
generates ATL transformations. Because I am doing code generation, it
is possible to specify "bad" transformations. For example, someone
could easily assign a value from a String attribute to a Real or
Integer. While I do generate toReal(), i could have a problem if the
value is not really a Real (for example "hello".toReal() gives a Number
format Exception).
I am wondering if we can make ATL transformations "Safe". That is, they
won't die (or throw a whole bunch of exceptions), but rather just
continue along happily. In this case, they would just return NaN or
something.
Thoughts? Ideas?
cheers,
ian
|
|
|
Re: [ATL] Safety of Model Transformations [message #18439 is a reply to message #17750] |
Fri, 23 February 2007 06:12 |
Eclipse User |
|
|
|
Originally posted by: irbull.cs.uvic.ca
Actually, ATL does continue well if there are problems, it just throws a
bunch of exceptions. Is there a way to suppress the errors / stack traces?
cheers,
ian
Ian Bull wrote:
> For the final part of my PhD I am creating a graphical editor that
> generates ATL transformations. Because I am doing code generation, it
> is possible to specify "bad" transformations. For example, someone
> could easily assign a value from a String attribute to a Real or
> Integer. While I do generate toReal(), i could have a problem if the
> value is not really a Real (for example "hello".toReal() gives a Number
> format Exception).
>
> I am wondering if we can make ATL transformations "Safe". That is, they
> won't die (or throw a whole bunch of exceptions), but rather just
> continue along happily. In this case, they would just return NaN or
> something.
>
> Thoughts? Ideas?
>
> cheers,
> ian
|
|
|
Re: [ATL] Safety of Model Transformations [message #18447 is a reply to message #18439] |
Fri, 23 February 2007 07:12 |
Frédéric Jouault Messages: 572 Registered: July 2009 |
Senior Member |
|
|
Hello Ian,
When you launch an ATL transformation programmatically, you specify a
Debugger (class org.atl.engine.vm.Debugger). The Debugger used in run
mode (i.e., org.atl.engine.vm.SimpleDebugger) only prints the stack
trace, whereas the Debugger used in debug mode (i.e.,
org.atl.engine.vm.NetworkDebugger) stops the execution an notifies the
debugger (e.g., Eclipse) using a TCP connection.
If you write your own Debugger class, you can simply ignore the errors.
It is, for instance, possible to extend org.atl.engine.vm.SimpleDebugger
and redefine the error(StackFrame frame, String msg, Exception e)
method, so that it does nothing special when an error occurs.
Alternatively, you may want to remember the errors and display them in a
different way.
Regards,
Frédéric Jouault
Ian Bull wrote:
> Actually, ATL does continue well if there are problems, it just throws a
> bunch of exceptions. Is there a way to suppress the errors / stack traces?
>
> cheers,
> ian
>
> Ian Bull wrote:
>> For the final part of my PhD I am creating a graphical editor that
>> generates ATL transformations. Because I am doing code generation, it
>> is possible to specify "bad" transformations. For example, someone
>> could easily assign a value from a String attribute to a Real or
>> Integer. While I do generate toReal(), i could have a problem if the
>> value is not really a Real (for example "hello".toReal() gives a
>> Number format Exception).
>>
>> I am wondering if we can make ATL transformations "Safe". That is,
>> they won't die (or throw a whole bunch of exceptions), but rather just
>> continue along happily. In this case, they would just return NaN or
>> something.
>>
>> Thoughts? Ideas?
>>
>> cheers,
>> ian
|
|
|
Re: [ATL] Safety of Model Transformations [message #18519 is a reply to message #18447] |
Fri, 23 February 2007 15:44 |
Eclipse User |
|
|
|
Originally posted by: irbull.cs.uvic.ca
Ah... Thanks a lot.
You rock!
p.s. are the ATL crew going to EclipseCon?
- ian
Frédéric Jouault wrote:
> Hello Ian,
>
> When you launch an ATL transformation programmatically, you specify a
> Debugger (class org.atl.engine.vm.Debugger). The Debugger used in run
> mode (i.e., org.atl.engine.vm.SimpleDebugger) only prints the stack
> trace, whereas the Debugger used in debug mode (i.e.,
> org.atl.engine.vm.NetworkDebugger) stops the execution an notifies the
> debugger (e.g., Eclipse) using a TCP connection.
>
> If you write your own Debugger class, you can simply ignore the errors.
> It is, for instance, possible to extend org.atl.engine.vm.SimpleDebugger
> and redefine the error(StackFrame frame, String msg, Exception e)
> method, so that it does nothing special when an error occurs.
>
> Alternatively, you may want to remember the errors and display them in a
> different way.
>
>
> Regards,
>
> Frédéric Jouault
>
>
> Ian Bull wrote:
>> Actually, ATL does continue well if there are problems, it just throws
>> a bunch of exceptions. Is there a way to suppress the errors / stack
>> traces?
>>
>> cheers,
>> ian
>>
>> Ian Bull wrote:
>>> For the final part of my PhD I am creating a graphical editor that
>>> generates ATL transformations. Because I am doing code generation,
>>> it is possible to specify "bad" transformations. For example,
>>> someone could easily assign a value from a String attribute to a Real
>>> or Integer. While I do generate toReal(), i could have a problem if
>>> the value is not really a Real (for example "hello".toReal() gives a
>>> Number format Exception).
>>>
>>> I am wondering if we can make ATL transformations "Safe". That is,
>>> they won't die (or throw a whole bunch of exceptions), but rather
>>> just continue along happily. In this case, they would just return
>>> NaN or something.
>>>
>>> Thoughts? Ideas?
>>>
>>> cheers,
>>> ian
|
|
| |
Goto Forum:
Current Time: Tue Mar 19 08:01:47 GMT 2024
Powered by FUDForum. Page generated in 0.02470 seconds
|