Bug 107007 - IModelManager#getModelFor apis don't throw UnsupportedEncoding exception
Summary: IModelManager#getModelFor apis don't throw UnsupportedEncoding exception
Status: RESOLVED INVALID
Alias: None
Product: WTP Source Editing
Classification: WebTools
Component: wst.sse (show other bugs)
Version: 0.7   Edit
Hardware: PC Windows XP
: P3 major (vote)
Target Milestone: 4.0   Edit
Assignee: Nitin Dahyabhai CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-08-15 06:53 EDT by Hirotaka Matsumoto CLA
Modified: 2010-02-16 11:18 EST (History)
7 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Hirotaka Matsumoto CLA 2005-08-15 06:53:14 EDT
IStructuredModel#save throws CoreException with UnsupportedEncoding 
exception so that we can catch this exception. However IModelManager#
getModelFor apis don't. They need to throw the same excepction as
IStructuredModel does.


.
Comment 1 David Williams CLA 2006-06-01 12:34:49 EDT
We'll look at this next release, as we make a more formal API. 
Unless I hear this is blocking some important scenerio. 
Comment 2 Susumu Fukuda CLA 2006-06-07 09:39:44 EDT
Similar bug for document loading. Bug #145754
Comment 3 Susumu Fukuda CLA 2006-06-08 01:15:38 EDT
Without the exception, we won't be able to detect data loss
in the following usecase.

Test Case:
Suppose that file (sample.jsp) contains following content:
--
<%@page pageEncoding="USASCII" %>
page content
--
Then, run the following code:
--
IDOMModel model = (IDOMModel)modelManager.getModelForEdit(file);
Text text = model.getDocument().createText("text");
model.getDocument().append(text);
model.save(file);
--
Actual Result:
 The code finishes without any error and the content gets to be "text",
 the original content is lost.

Expected Result:
 Exception on creating model.

On the other hand, we also need a way to obtain IStructuredModel
regardless of encoding error when EncodingRule.IGNORE_CONVERSON_ERROR
is passed to getModelFor API for proper error recovery, as it used to be.


I cannot find proper workaround at this point, but it would be of help
if I could get an underlying ResourceTextFileBuffer properly, as it holds
encoding error in its status.
Comment 4 David Williams CLA 2006-06-08 01:59:00 EDT
I'll admit, we, and the platform text, need a consistent story here, but have you looked at using 'IContentDescriptionExtended'
for your use case?

If you can check the content type, then you can check the contentDescription 
properties. And, if you find "UNSUPPORTED_CHARSET" set to some value, that tells 
you the same thing that the excecption would. 

Let me know if you like/agree with this strategy, and we'll look at making it a better API next release. 


Comment 5 Susumu Fukuda CLA 2006-06-09 09:06:52 EDT
OK. I also think we need to be consistent to Platform Text.
For this release, I'll put workarounds using 
the IContentDescriptionExtended#UNSUPPORTED_CHARSET.
(and ITextFileBuffer, used for error recovery.)
Comment 6 Ian Tewksbury CLA 2010-02-05 16:09:29 EST
I took a look at the IModelManager and there are now getModelFor* methods that throw UnsupportedEncodingException but they are now also depreciated with the message "encoding is handled automatically based on the file's contents or user preferences".  Time to resolve this one.
Comment 7 Nick Sandonato CLA 2010-02-16 11:18:57 EST
Encoding is automatically handled by the contents or user preferences.